Open Stack

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 [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'

+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 
> 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

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.

+1000

> - 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.

+1

> 
> 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.
> 
> [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
>