Open Stack

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 <rmeggins at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev