Hi Rich, Sorry, I meant to link [0] to https://bugs.launchpad.net/keystone/+bug/1470635 More responses inline.
On Thu, Jul 30, 2015 at 5:38 PM, Rich Megginson <rmegg...@redhat.com> wrote: >> 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. > But not vice versa. > But you said "We are using Keystone v2.0 API everywhere currently." - Are > you trying to move to use v3? Not yet. > 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? No. Avoiding that is better for now. > >> >> 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. Yes, the puppet-keystone openstack.rb providers. Almost, except they don't update the identity_api_version. It just passes the version from ENV or $HOME/openrc https://github.com/openstack/puppet-openstacklib/blob/master/lib/puppet/provider/openstack/credentials.rb > >> >> 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. Updating all clients to v3 is more effort at this point and v3 keystone is not targeted for Fuel 7.0. >> >> 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. The issue, concisely, is creating service_endpoints with v2.0 API and other keystone resources with v3 API using one /root/openrc file. __________________________________________________________________________ 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