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

Pavlo Shchelokovskyy pshchelokovskyy at mirantis.com
Wed May 24 09:46:07 UTC 2017


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/
[1] 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170524/d1dc4a2e/attachment.html>


More information about the OpenStack-dev mailing list