Open Stack

On 07/30/2015 10:54 AM, Matthew Mosesohn wrote:
> 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.

Ok.  Please add me to the reviews.

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