The problem appears to be much more concise. The provider sets identity_api_version okay, but doesn't alter OS_AUTH_URL api version. That's the only reason why this is breaking.
It is broken in 2 places: in openstacklib's credentials class and in keystone base provider. The keystone auth_endpoint logic seems to just duplicate that of openstacklib's credentials class, so I think it would make sense to consolidate that. I will prepare a patch to puppet-keystone and puppet-openstacklib to address this. On Thu, Jul 30, 2015 at 6:14 PM, Rich Megginson <rmegg...@redhat.com> wrote: > On 07/30/2015 08:53 AM, Matthew Mosesohn wrote: >> >> 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 > > > Ok, I see. The intention of that code is that, if you specify something in > ENV/openrc, it will override the default settings in the provider. > > What if the puppet-keystone openstack providers did not allow you to > override the api version/url version with ENV/openrc? Would that solve the > problem? > >> >>>> 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 > > > > __________________________________________________________________________ > 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
