Hi all, There are several problems or inefficiencies in how we are dealing with auth to other services. Although it became much better in Newton, some things are still to be improved and I like to discuss how to tackle those and my ideas for that.
Keystone endpoints =============== Apparently since February-ish DevStack no longer sets up 'internal' endpoints for most of the services in core devstack . Luckily we were not broken by that right away - although when discovering a service endpoint from keystone catalog we default to 'internal' endpoint , for most services our devstack plugin still configures explicit service URL in the corresponding config section, and thus the service discovery from keystone never takes place (or that code path is not tested by functional/integration testing). AFAIK different endpoint types (internal vs public) are still quite used by deployments (and IMO rightfully so), so we have to continue supporting that. I propose to take the following actions: - in our devstack plugin, stop setting up the direct service URLs in config, always use keystone catalog for discovery - in every conf section related to external service add 'endpoint_type=[internal|public]' option, defaulting to 'internal', with a warning in option description (and validated on conductor start) that it will be changed to 'public' in the next release - use those values from CONF wherever we ask for service URL from catalog or instantiate client with session. - populate these options in our devstack plugin to be 'public' - in Queens, switch the default to 'public' and use defaults in devstack plugin, remove warnings. Unify clients creation ================ again, in those config sections related to service clients, we have many options to instantiate clients from (especially glance section, see my other recent ML about our image service code). Many of those seem to be from the time when keystone catalog was missing some functionality or not existing at all, and keystoneauth lib abstracting identity and client sessions was not there either. To simplify setup and unify as much code as possible I'd like to propose the following: - in each config section for service client add (if missing) a '<service>_url' option that should point to the API of given service and will be used *only in noauth mode* when there's no Keystone catalog to discover the service endpoint from - in the code creating service clients, always create a keystoneauth session from config sections, using appropriate keystoneauth identity plugin - 'token_endpoint' with fake token <service>_url for noauth mode, 'password' for service user client, 'token' when using a token from incoming request. The latter will have a benefit to make it possible for the session to reauth itself when user token is about to expire, but might require changes in some public methods to pass in the full task.context instead of just token - always create clients from sessions. Although AFAIK all clients ironic uses already support this, some in ironic code (e.g. glance) still always create a client from token and endpoint directly. - deprecate some options explicitly registered by ironic in those sections that are becoming redundant - including those that relate to HTTP session settings (like timeout, retries, SSL certs and settings) as those will be used from options registered by keystoneauth Session, and those multiple options that piece together a single service URL. This will decrease the complexity of service client-related code and will make configuring those cleaner. Of course all of this has to be done minding proper deprecation process, although that might complicate things (as usual :/). Legacy auth ========= Probably not worth specific mention, but we implemented a proper keystoneauth-based loading of client auth options back in Newton almost a year ago, so the code attempting to load auth for clients in a deprecated way from "[keystone_authtoken]" section can be safely removed already. As always, I'm eager to hear your comments.  https://review.openstack.org/#/c/433272/  http://git.openstack.org/cgit/openstack/ironic/tree/ ironic/common/keystone.py#n118 Best regards, Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev