[openstack-dev] [Fuel][Puppet] Keystone V2/V3 service endpoints

Matthew Mosesohn mmosesohn at mirantis.com
Thu Jul 30 14:24:37 UTC 2015


Hi all,

It seems that I've reached an impasse with
https://review.openstack.org/#/q/topic:bp/detach-components-from-controllers,n,z
in Keystone with regards to Kilo puppet manifests. One of the
objectives is the ability to deploy Keystone on a separate node from
the controllers.

Here is what we know:

We are using Keystone v2.0 API everywhere currently.

Most Keystone providers for users, services, etc, use V3 API through
openstackclient

Keystone provider for service endpoints is still on V2. This is
because v2.0 clients can't see v3 endpoints. It's "by design" to not
be forward compatible[0].

There is a patch upstream[1] that enables V3 service endpoint
creation, but v2.0 users/clients will not see these endpoints.

Identity v2 and v3 behavior of openstackclient are vastly different.
There is nothing backward/forward compatible among the two, so it's a
hassle to deal with them in parallel.

openstackclient fails on v3 parameters unless version 3 is explicitly enabled.

What we can do to go forward?

Option 1: Keep v2.0 API data in openrc and hack v3 keystone providers,
updating ENV with 2 vars:
OS_IDENTITY_API_VERSION=3
OS_AUTH_URL=$(echo "$OLD_OS_AUTH_URL" | sed -e s'/v2.0/v3/')
or their equivalent in command line parameters

Option 2: Update to v3 Identity API for all services and accept the
unmerged patch[1]. This route requires the most disruptive changes
because of [0] and I would like to avoid this.

Option 3: Revert puppet-keystone to version 5.1.0 which is before v3
became mandatory.


I'd like to see what is possible with Option 1 because it should be
possible to use the existing providers in puppet-keystone master
without too many hoops to make them all work cleanly. I'd really
prefer being able to provide all these parameters to the keystone
provider, rather than relying on the /root/openrc file or exporting
shell vars, but getting this issue unstuck is really the most
important.


[0] https://review.openstack.org/#/c/196943/
[1] https://review.openstack.org/#/c/178456/24

Best Regards,
Matthew Mosesohn



More information about the OpenStack-dev mailing list