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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
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
