[openstack-dev] [ironic] using keystone right - catalog, endpoints, tokens and noauth

Eric Fried openstack at fried.cc
Wed May 24 17:51:00 UTC 2017


Pavlo-

	There's a blueprint [1] whereby we're trying to address a bunch of
these same concerns in nova.  You can see the first part in action here
[2].  However, it has become clear that nova is just one of the many
services that would benefit from get_service_url().  With the full
support of mordred (let's call it The Full Monty), we've got our sights
on moving that method into ksa itself for that purpose.

	Please have a look at this blueprint and change set.  Let us know if
your concerns would be addressed if this were available to you from ksa.

[1]
https://specs.openstack.org/openstack/nova-specs/specs/pike/approved/use-service-catalog-for-endpoints.html
[2] https://review.openstack.org/#/c/458257/

			Thanks,
			efried

On 05/24/2017 04:46 AM, Pavlo Shchelokovskyy wrote:
> 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 [0].
> Luckily we were not broken by that right away - although when
> discovering a service endpoint from keystone catalog we default to
> 'internal' endpoint [1], 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.
> 
> [0] https://review.openstack.org/#/c/433272/
> <https://review.openstack.org/#/c/433272/>
> [1] http://git.openstack.org/cgit/openstack/ironic/tree/ironic/common/keystone.py#n118
> <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 <http://www.mirantis.com>
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list