Open Stack

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