yahoo-eng-team team mailing list archive

[Colleen Murphy <colleen@xxxxxxxxxxx>]

Public bug reported:

As of this bugfix in novaclient, federated users cannot log in to
horizon:

https://bugs.launchpad.net/python-novaclient/+bug/1658963

Before this bugfix, horizon would attempt to list nova extensions using
what was apparently the wrong class, and the error would be caught and
quietly logged as such:

 Call to list supported extensions failed. This is likely due to a
problem communicating with the Nova endpoint. Host Aggregates panel will
not be displayed.

The dashboard would display:

 Error: Unable to retrieve usage information.

but at least the user was logged into the dashboard.

The error that was being hidden was:

 __init__() takes at least 3 arguments (2 given)

Now that that is fixed, horizon makes it further but fails to
authenticate the federated user when attempting this request, giving the
traceback here:

 http://paste.openstack.org/show/596929/

The problem lies somewhere between keystoneauth, novaclient, and
horizon.

keystoneauth:

When keystoneauth does version discovery, it first tries the Identity
v2.0 API, and finding no domain information in the request, returns that
API as the Identity endpoint. Modifying keystoneauth to not stop there
and continue trying the v3 API, even though it lacks domain information,
allows the user to successfully log in:

 http://paste.openstack.org/show/596930/

I'm not really sure why that works or what would break with that change.

novaclient:

When creating a Token plugin the novaclient is aware of a project's
domain but not of a domain on its own or of a default domain:

 http://git.openstack.org/cgit/openstack/python-
novaclient/tree/novaclient/client.py#n137

keystoneauth relies on having default_domain_(id|name),
domain_(id|name), or project_domain(id|name) set, and novaclient isn't
receiving information about the project_domain(id|name) and isn't
capable of sending any other domain information when using the Token
plugin, which it must for a federated user.

horizon:

For federated users novaclient is only set up to pass along domain info
for the project, which horizon doesn't store in its user object:

http://git.openstack.org/cgit/openstack/django_openstack_auth/tree/openstack_auth/user.py#n202

However things seem to just work if we fudge the user_domain_id as the
project_domain_id, though that is obviously not a good solution:

 http://paste.openstack.org/show/596933/

** Affects: horizon
     Importance: Undecided
         Status: New

** Affects: keystoneauth
     Importance: Undecided
         Status: New

** Affects: python-novaclient
     Importance: Undecided
         Status: New

** Also affects: python-novaclient
   Importance: Undecided
       Status: New

** Also affects: horizon
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1660436

Title:
  Federated users cannot log into horizon

Status in OpenStack Dashboard (Horizon):
  New
Status in keystoneauth:
  New
Status in python-novaclient:
  New

Bug description:
  As of this bugfix in novaclient, federated users cannot log in to
  horizon:

  https://bugs.launchpad.net/python-novaclient/+bug/1658963

  Before this bugfix, horizon would attempt to list nova extensions
  using what was apparently the wrong class, and the error would be
  caught and quietly logged as such:

   Call to list supported extensions failed. This is likely due to a
  problem communicating with the Nova endpoint. Host Aggregates panel
  will not be displayed.

  The dashboard would display:

   Error: Unable to retrieve usage information.

  but at least the user was logged into the dashboard.

  The error that was being hidden was:

   __init__() takes at least 3 arguments (2 given)

  Now that that is fixed, horizon makes it further but fails to
  authenticate the federated user when attempting this request, giving
  the traceback here:

   http://paste.openstack.org/show/596929/

  The problem lies somewhere between keystoneauth, novaclient, and
  horizon.

  keystoneauth:

  When keystoneauth does version discovery, it first tries the Identity
  v2.0 API, and finding no domain information in the request, returns
  that API as the Identity endpoint. Modifying keystoneauth to not stop
  there and continue trying the v3 API, even though it lacks domain
  information, allows the user to successfully log in:

   http://paste.openstack.org/show/596930/

  I'm not really sure why that works or what would break with that
  change.

  novaclient:

  When creating a Token plugin the novaclient is aware of a project's
  domain but not of a domain on its own or of a default domain:

   http://git.openstack.org/cgit/openstack/python-
  novaclient/tree/novaclient/client.py#n137

  keystoneauth relies on having default_domain_(id|name),
  domain_(id|name), or project_domain(id|name) set, and novaclient isn't
  receiving information about the project_domain(id|name) and isn't
  capable of sending any other domain information when using the Token
  plugin, which it must for a federated user.

  horizon:

  For federated users novaclient is only set up to pass along domain
  info for the project, which horizon doesn't store in its user object:

  http://git.openstack.org/cgit/openstack/django_openstack_auth/tree/openstack_auth/user.py#n202

  However things seem to just work if we fudge the user_domain_id as the
  project_domain_id, though that is obviously not a good solution:

   http://paste.openstack.org/show/596933/

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1660436/+subscriptions