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