[Yahoo-eng-team] [Bug 1558876] [NEW] Inconsistent URLs reported from discovery endpoints
Public bug reported: TLDR; the URLs returned from /, /v2.0 and /v3 are inconsistent. In detail: GET / returns v3.4: http://172.16.14.31:35357/v3/ v2.0: http://172.16.14.31:35357/v2.0/ GET /v2.0 returns http://172.16.14.31:35357/v2.0/ GET /v3 returns: http://192.168.14.31:5000/v3/ Notice the /v3 URL is different, it reflects the public endpoint and the others are the admin endpoints. The end effect is that 'openstack catalog list' (or any openstack CLI command) hangs when I access the v3 API because it gets redirected to an IP that I can't connect to (my client side can only see admin URLs). More detail: My catalog has the following in it: +---+--+ | Field | Value| +---+--+ | endpoints | regionOne| | | admin: http://172.16.14.31:35357 | | | regionOne| | | internal: http://172.16.14.31:5000 | | | regionOne| | | public: http://192.168.14.31:5000 | | | | | id| 4709cfbbba2747f680750d0bcb31ef51 | | name | Identity Service | | type | identity | +---+--+ Querying at / $ curl http://172.16.14.20:35357/|python -m json.tool { "versions": { "values": [ { "id": "v3.4", "links": [ { "href": "http://172.16.14.31:35357/v3/";, "rel": "self" } ], "media-types": [ { "base": "application/json", "type": "application/vnd.openstack.identity-v3+json" } ], "status": "stable", "updated": "2015-03-30T00:00:00Z" }, { "id": "v2.0", "links": [ { "href": "http://172.16.14.31:35357/v2.0/";, "rel": "self" }, { "href": "http://docs.openstack.org/";, "rel": "describedby", "type": "text/html" } ], "media-types": [ { "base": "application/json", "type": "application/vnd.openstack.identity-v2.0+json" } ], "status": "stable", "updated": "2014-04-17T00:00:00Z" } ] } } Querying at /v2.0: $ curl http://172.16.14.20:35357/v2.0|python -m json.tool { "version": { "id": "v2.0", "links": [ { "href": "http://172.16.14.31:35357/v2.0/";, "rel": "self" }, { "href": "http://docs.openstack.org/";, "rel": "describedby", "type": "text/html" } ], "media-types": [ { "base": "application/json", "type": "application/vnd.openstack.identity-v2.0+json" } ], "status": "stable", "updated": "2014-04-17T00:00:00Z" } } And at /v3.0: $ curl http://172.16.14.20:35357/v3|python -m json.tool { "version": { "id": "v3.4", "links": [ { "href": "http://192.168.14.31:5000/v3/";, "rel": "self" } ], "media-types": [ { "base": "application/json", "type": "application/vnd.openstack.identity-v3+json" } ], "status": "stable", "updated": "2015-03-30T00:00:00Z" } } ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1558876 Title: Inconsistent URLs reported from discovery endpoints Status in OpenStack Identity (keystone): New Bug description: TLDR; the URLs returned from /, /v2.0 and /v3 are inconsistent. In detail: GET / returns v3.4: http://172.16.14.31:35357/v3/ v2.0: http://172.16.14.31:35357/v2.0/ GET /v2.0 returns http://172.16.14.31:35357/v2.0/ GET /v3 returns: http://192.168.14.31:5000/v3/ Notice the /v3 URL is different, it reflects the public endpoint and the others are the admin endpoints. The end effect is that 'openstack catalog list' (or any openstack CLI command) hangs when I access the v3 API because it gets redirected to an IP that I can't connec
[Yahoo-eng-team] [Bug 1547331] [NEW] AuthorizationFailure: Authorization failed: Cannot authenticate without an auth_url
Public bug reported: If you create a client using a session and an endpoint override, if you then call authenticate() on the client it blows up with the error AuthorizationFailure: Authorization failed: Cannot authenticate without an auth_url There is a comment in the code that the newer behaviour with sessions is to now authenticate with the server on the first call, but: - is authenticate() still supposed to work? - if not, how can you pre-auth before any work is done to validate user-supplied credentials? ** Affects: python-keystoneclient Importance: Undecided Status: New ** Project changed: keystone => python-keystoneclient -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1547331 Title: AuthorizationFailure: Authorization failed: Cannot authenticate without an auth_url Status in python-keystoneclient: New Bug description: If you create a client using a session and an endpoint override, if you then call authenticate() on the client it blows up with the error AuthorizationFailure: Authorization failed: Cannot authenticate without an auth_url There is a comment in the code that the newer behaviour with sessions is to now authenticate with the server on the first call, but: - is authenticate() still supposed to work? - if not, how can you pre-auth before any work is done to validate user-supplied credentials? To manage notifications about this bug go to: https://bugs.launchpad.net/python-keystoneclient/+bug/1547331/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1520383] [NEW] Tests that need policy.json can never find it
Public bug reported: I am writing some tests that inherit from RestfulTestCase. The server- side of the calls that the tests make are doing some checks that require policy.json to be read in. However, it seems as though the file can't ever be found. Looking at oslo_config, it searches these directories: def _get_config_dirs(project=None): """Return a list of directories where config files may be located. :param project: an optional project name If a project is specified, following directories are returned:: ~/.${project}/ ~/ /etc/${project}/ /etc/ Otherwise, these directories:: ~/ /etc/ """ So basically under $HOME or /etc. The ConfigOpts.find_file() func also looks in any directory specified with the --config-dir option. When running the tests, $HOME is set to a temp dir for each and every test, and --config-dir is not set at all. This currently seems to make it impossible for policy.json to be ever discovered in test runs. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1520383 Title: Tests that need policy.json can never find it Status in OpenStack Identity (keystone): New Bug description: I am writing some tests that inherit from RestfulTestCase. The server-side of the calls that the tests make are doing some checks that require policy.json to be read in. However, it seems as though the file can't ever be found. Looking at oslo_config, it searches these directories: def _get_config_dirs(project=None): """Return a list of directories where config files may be located. :param project: an optional project name If a project is specified, following directories are returned:: ~/.${project}/ ~/ /etc/${project}/ /etc/ Otherwise, these directories:: ~/ /etc/ """ So basically under $HOME or /etc. The ConfigOpts.find_file() func also looks in any directory specified with the --config-dir option. When running the tests, $HOME is set to a temp dir for each and every test, and --config-dir is not set at all. This currently seems to make it impossible for policy.json to be ever discovered in test runs. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1520383/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1479578] [NEW] Domain-specific config breaks some ops
Public bug reported: I set up a multi-domain config on my devstack and tried to do a simple: $ openstack user list with project-scoped environment variables (in fact I downloaded the admin-openrc.sh from Horizon). This results in: ERROR: openstack The request you have made requires authentication. (Disable debug mode to suppress these details.) (HTTP 401) (Request-ID: req-b687e823-9896-4905-83d3-b1e45fa966ed) If I disable domain-specific configs in the keystone.conf, it works again. If it *is* enabled, I can force a domain-specific request using something like: $ OS_TENANT_ID= OS_TENANT_NAME= OS_PROJECT_NAME= openstack --os-domain- name user list However if I specify the default domain then I get this: ERROR: openstack User 0fa9633d884a42448bbd386778ca6b87 has no access to domain default (Disable debug mode to suppress these details.) (HTTP 401) (Request-ID: req-65e053e4-33c2-4b7b-aedf-30d3ef88735c) ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1479578 Title: Domain-specific config breaks some ops Status in Keystone: New Bug description: I set up a multi-domain config on my devstack and tried to do a simple: $ openstack user list with project-scoped environment variables (in fact I downloaded the admin-openrc.sh from Horizon). This results in: ERROR: openstack The request you have made requires authentication. (Disable debug mode to suppress these details.) (HTTP 401) (Request- ID: req-b687e823-9896-4905-83d3-b1e45fa966ed) If I disable domain-specific configs in the keystone.conf, it works again. If it *is* enabled, I can force a domain-specific request using something like: $ OS_TENANT_ID= OS_TENANT_NAME= OS_PROJECT_NAME= openstack --os- domain-name user list However if I specify the default domain then I get this: ERROR: openstack User 0fa9633d884a42448bbd386778ca6b87 has no access to domain default (Disable debug mode to suppress these details.) (HTTP 401) (Request-ID: req-65e053e4-33c2-4b7b-aedf-30d3ef88735c) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1479578/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1474660] [NEW] Stack trace if federation mapping references unavailable request variables
Public bug reported: If the federation mapping depends on a request variable that is not present (e.g. REMOTE_USER is not set) then keystone blows up with a stack trace. Ideally, something a little more user-friendly might happen. Trace below: [Wed Jul 15 04:29:44 2015] [error] 1827 ERROR keystone.common.wsgi [-] tuple index out of range [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi Traceback (most recent call last): [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/common/wsgi.py", line 239, in __call__ [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi result = method(context, **params) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/contrib/federation/controllers.py", line 292, in federated_sso_auth [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi protocol_id) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/contrib/federation/controllers.py", line 267, in federated_authentication [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi return self.authenticate_for_token(context, auth=auth) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/controllers.py", line 377, in authenticate_for_token [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi self.authenticate(context, auth_info, auth_context) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/controllers.py", line 502, in authenticate [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi auth_context) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/plugins/mapped.py", line 70, in authenticate [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi self.identity_api) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/plugins/mapped.py", line 144, in handle_unscoped_token [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi federation_api, identity_api) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/auth/plugins/mapped.py", line 193, in apply_mapping_filter [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi mapped_properties = rule_processor.process(assertion) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/contrib/federation/utils.py", line 471, in process [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi new_local = self._update_local_mapping(local, direct_maps) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/contrib/federation/utils.py", line 613, in _update_local_mapping [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi new_value = self._update_local_mapping(v, direct_maps) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/contrib/federation/utils.py", line 615, in _update_local_mapping [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi new_value = v.format(*direct_maps) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi IndexError: tuple index out of range ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1474660 Title: Stack trace if federation mapping references unavailable request variables Status in Keystone: New Bug description: If the federation mapping depends on a request variable that is not present (e.g. REMOTE_USER is not set) then keystone blows up with a stack trace. Ideally, something a little more user-friendly might happen. Trace below: [Wed Jul 15 04:29:44 2015] [error] 1827 ERROR keystone.common.wsgi [-] tuple index out of range [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi Traceback (most recent call last): [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/common/wsgi.py", line 239, in __call__ [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi result = method(context, **params) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keystone/contrib/federation/controllers.py", line 292, in federated_sso_auth [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi protocol_id) [Wed Jul 15 04:29:44 2015] [error] 1827 TRACE keystone.common.wsgi File "/opt/stack/keystone/keysto
[Yahoo-eng-team] [Bug 1470718] [NEW] Federation mapping schema validation for "local" attributes could do better
Public bug reported: I was bitten just now by getting my local attributes slightly wrong and put the "type" key outside of the "user" block like this: "local": [ { "user": { "name": "{0}", "domain": {"id": "default"} }, "type": "local" } ], Whereas it should have been like this: "local": [ { "user": { "name": "{0}", "domain": {"id": "default"}, "type": "local" } } ], The end result was a validation error about not having a group. It would have taken me ~3 hours less of digging (thanks stevemar!) if the validation had pointed this error out. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1470718 Title: Federation mapping schema validation for "local" attributes could do better Status in OpenStack Identity (Keystone): New Bug description: I was bitten just now by getting my local attributes slightly wrong and put the "type" key outside of the "user" block like this: "local": [ { "user": { "name": "{0}", "domain": {"id": "default"} }, "type": "local" } ], Whereas it should have been like this: "local": [ { "user": { "name": "{0}", "domain": {"id": "default"}, "type": "local" } } ], The end result was a validation error about not having a group. It would have taken me ~3 hours less of digging (thanks stevemar!) if the validation had pointed this error out. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1470718/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1452955] [NEW] Client does not catch exceptions when making a token authentication request
Public bug reported: keystoneclient.auth.identity.v3.token.TokenMethod does a session.post() without catching exceptions. In my case, I had a misconfigured DNS which meant that this post() never succeeded, however the error that ends up going back to Horizon is a simplified: "Login failed: An error occurred authenticating. Please try again later." which makes no mention of the underlying cause, nor do the keystone logs. This caused me an enormous amount of wasted time debugging, the error could certainly be improved here! ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1452955 Title: Client does not catch exceptions when making a token authentication request Status in OpenStack Identity (Keystone): New Bug description: keystoneclient.auth.identity.v3.token.TokenMethod does a session.post() without catching exceptions. In my case, I had a misconfigured DNS which meant that this post() never succeeded, however the error that ends up going back to Horizon is a simplified: "Login failed: An error occurred authenticating. Please try again later." which makes no mention of the underlying cause, nor do the keystone logs. This caused me an enormous amount of wasted time debugging, the error could certainly be improved here! To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1452955/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1452197] [NEW] websso docs have incorrect/incomplete Apache config snippets
Public bug reported: The documentation referenced here http://docs.openstack.org/developer/keystone/extensions/websso.html has a few problems: 1. The Apache config in all the examples is incorrect, it has an opening tag bug closes with 2. The mod_shib snippet needs the same Shibboleth settings as referenced in this page: http://docs.openstack.org/developer/keystone/extensions/shibboleth.html ** Affects: keystone Importance: Low Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1452197 Title: websso docs have incorrect/incomplete Apache config snippets Status in OpenStack Identity (Keystone): New Bug description: The documentation referenced here http://docs.openstack.org/developer/keystone/extensions/websso.html has a few problems: 1. The Apache config in all the examples is incorrect, it has an opening tag bug closes with 2. The mod_shib snippet needs the same Shibboleth settings as referenced in this page: http://docs.openstack.org/developer/keystone/extensions/shibboleth.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1452197/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1436166] [NEW] Problems with images bubble up as a simple "There are not enough hosts available"
Public bug reported: When starting a new instance, I received the generic "There are not enough hosts available" error, but the real reason was buried in logs, which was that the image I was trying to use was corrupt. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1436166 Title: Problems with images bubble up as a simple "There are not enough hosts available" Status in OpenStack Compute (Nova): New Bug description: When starting a new instance, I received the generic "There are not enough hosts available" error, but the real reason was buried in logs, which was that the image I was trying to use was corrupt. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1436166/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1311700] Re: "Setting oauth clockskew" messages on booting node; slows down boot
Ok that message comes out of cloud-init. I've added a bugtask for Scott's comments to see if anything can be done in MAAS. ** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: maas Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1311700 Title: "Setting oauth clockskew" messages on booting node; slows down boot Status in Init scripts for use on cloud images: New Status in MAAS: Incomplete Bug description: On booting nodes for enlistment, commissioning, and starting, I sometimes see repeated errors like this: 2014-04-23 14:15:50,622 - DataSourceMAAS.py[WARNING]: Setting oauth clockskew to -2 (See attached screen shot, too.) These scroll by, once every second or so, for about a minute before the node continues booting. Although a minute here or there isn't all THAT big of a deal, it would be nice to see this delay go away, particularly for occasions when I have to repeatedly test a node. Here's my version information: $ dpkg -l '*maas*'|cat Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-===--=== ii maas 1.5+bzr2252-0ubuntu1all MAAS server all-in-one metapackage ii maas-cli 1.5+bzr2252-0ubuntu1all MAAS command line API tool ii maas-cluster-controller 1.5+bzr2252-0ubuntu1all MAAS server cluster controller ii maas-common 1.5+bzr2252-0ubuntu1all MAAS server common files ii maas-dhcp 1.5+bzr2252-0ubuntu1all MAAS DHCP server ii maas-dns 1.5+bzr2252-0ubuntu1all MAAS DNS server ii maas-region-controller 1.5+bzr2252-0ubuntu1all MAAS server complete region controller ii maas-region-controller-min 1.5+bzr2252-0ubuntu1all MAAS Server minimum region controller ii python-django-maas 1.5+bzr2252-0ubuntu1all MAAS server Django web framework ii python-maas-client 1.5+bzr2252-0ubuntu1all MAAS python API client ii python-maas-provisioningserver 1.5+bzr2252-0ubuntu1all MAAS server provisioning libraries To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1311700/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1303925] Re: commissioning fails silently if a node can't reach the region controller
Thanks James. Scott, cloud-init is hanging without getting any data from MAAS. It seems to me that there should be at least a last-ditch way of reporting the failure back somewhere? This is possibly a dupe of bug 1237215 ** Also affects: curtin Importance: Undecided Status: New ** No longer affects: curtin ** Also affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1303925 Title: commissioning fails silently if a node can't reach the region controller Status in Init scripts for use on cloud images: New Status in MAAS: Triaged Bug description: We recently had a node which completely refused to commission in MAAS. After (literally) several man days of debugging, we figured out that it was because the node couldn't talk to the region controller over HTTP. Obviously, that's ultimately our mistake/problem, but MAAS could have been a lot better at helping us to help ourselves; currently, there's absolutely no indication from the boot process that the HTTP connection to the region controller is the problem. Attached is the serial console output (from the point of boot) for the node that was failing to commission. 91.189.94.35 is the MAAS region controller and 91.189.88.20 is the MAAS cluster controller. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1303925/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1303925] Re: commissioning fails silently if a node can't reach the region controller
James, was it hanging or shutting down after that error in the log? ** Also affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1303925 Title: commissioning fails silently if a node can't reach the region controller Status in Init scripts for use on cloud images: New Status in MAAS: Triaged Bug description: We recently had a node which completely refused to commission in MAAS. After (literally) several man days of debugging, we figured out that it was because the node couldn't talk to the region controller over HTTP. Obviously, that's ultimately our mistake/problem, but MAAS could have been a lot better at helping us to help ourselves; currently, there's absolutely no indication from the boot process that the HTTP connection to the region controller is the problem. Attached is the serial console output (from the point of boot) for the node that was failing to commission. 91.189.94.35 is the MAAS region controller and 91.189.88.20 is the MAAS cluster controller. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1303925/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp