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

Rich Megginson rmeggins at redhat.com
Thu Jul 30 14:38:21 UTC 2015

On 07/30/2015 08:24 AM, Matthew Mosesohn wrote:
> 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].

I don't understand - [0] is a link to an ansible review?
> There is a patch upstream[1] that enables V3 service endpoint
> creation, but v2.0 users/clients will not see these endpoints.

Right.  I'm not sure what the problem is - v3 clients can see the 
endpoints created with v2.

Note that in Keystone, resources like roles, services, and endpoints are 
_not_ domain scoped, and therefore do not need to use the v3 api to CRUD.

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

But you said "We are using Keystone v2.0 API everywhere currently." - 
Are you trying to move to use v3?

> What we can do to go forward?

I'm still not sure what the problem is.  Are you trying to move to use 
v3 for auth, and use v3 resources like domains?

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

I don't understand.  When you say "v3 keystone providers" are you 
talking about the puppet-keystone openstack.rb providers?  If so, they 
already do something similar to the above.

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

I don't understand why you need [1] which makes keystone_endpoint use 
the v3 api.  v3 clients can see endpoints created with the v2 api.

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

I'm still not sure what the issue is, what you are prevented from doing.

> [0] https://review.openstack.org/#/c/196943/
> [1] https://review.openstack.org/#/c/178456/24
> Best Regards,
> Matthew Mosesohn
> __________________________________________________________________________
> 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

More information about the OpenStack-dev mailing list