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