[Yahoo-eng-team] [Bug 1558876] [NEW] Inconsistent URLs reported from discovery endpoints

2016-03-19 Thread Julian Edwards 
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

2016-02-18 Thread Julian Edwards 
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

2015-11-26 Thread Julian Edwards 
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

2015-07-29 Thread Julian Edwards 
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

2015-07-14 Thread Julian Edwards 
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

2015-07-01 Thread Julian Edwards 
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

2015-05-07 Thread Julian Edwards 
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

2015-05-06 Thread Julian Edwards 
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"

2015-03-24 Thread Julian Edwards 
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

2014-04-27 Thread Julian Edwards 
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

2014-04-08 Thread Julian Edwards 
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

2014-04-07 Thread Julian Edwards 
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