Open Stack

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

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