yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #61142
[Bug 1660436] Re: Federated users cannot log into horizon
Marked as invalid for keystone projects and novaclient. The fix was
centralized to Horizon and DOA.
** Changed in: keystone
Status: New => Invalid
** Changed in: python-novaclient
Status: New => Invalid
** Changed in: keystoneauth
Status: New => Invalid
** Also affects: django-openstack-auth
Importance: Undecided
Status: New
** Changed in: django-openstack-auth
Status: New => Fix Released
** Changed in: keystone
Milestone: ocata-rc1 => None
** Changed in: keystone
Assignee: Colleen Murphy (krinkle) => (unassigned)
** Changed in: keystone
Importance: Critical => Undecided
--
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/1660436
Title:
Federated users cannot log into horizon
Status in django-openstack-auth:
Fix Released
Status in OpenStack Dashboard (Horizon):
In Progress
Status in OpenStack Identity (keystone):
Invalid
Status in keystoneauth:
Invalid
Status in python-novaclient:
Invalid
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/django-openstack-auth/+bug/1660436/+subscriptions
References