[openstack-dev] [ironic] using keystone right - catalog, endpoints, tokens and noauth
dtantsur at redhat.com
Thu May 25 08:31:09 UTC 2017
On 05/24/2017 11: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 .
> 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
> 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'
+1 to all this
> - in Queens, switch the default to 'public' and use defaults in devstack plugin,
> remove warnings.
-1 here. The semantic of "internal" is much closer to what we want. What we
actually need is a way to provide a prioritized list of interfaces. So this
would be ["internal", "public"], which means "take internal if it exists,
otherwise take public". I'm pretty sure no clients support anything like that.
> 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
> - 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
As Monty noticed, we seem to have endpoint_override already.
> - 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.
Yes please. We've already removed it from ironic-inspector.
> As always, I'm eager to hear your comments.
>  https://review.openstack.org/#/c/433272/
> 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
More information about the OpenStack-dev