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