On 08/13/2015 12:41 AM, Gilles Dubreuil wrote:
Hi Matthew,
On 11/08/15 01:14, Rich Megginson wrote:
On 08/10/2015 07:46 AM, Matthew Mosesohn wrote:
Sorry to everyone for bringing up this old thread, but it seems we may
need more openstackclient/keystone experts to settle this.
I'm referring to the comments in https://review.openstack.org/#/c/207873/
Specifically comments from Richard Megginson and Gilles Dubreuil
indicating openstackclient behavior for v3 keystone API.
A few items seem to be under dispute:
1 - Keystone should be able to accept v3 requests at
<http://keystone-server:5000/>http://keystone-server:5000/
I don't think so. Keystone requires the version suffix "/v2.0" or "/v3".
Yes, if the public endpoint is set without a version then the service
can deal with either version.
http://paste.openstack.org/raw/412819/
That is not true for the admin endpoint (authentication is already done,
the admin services deals only with tokens), at least for now, Keystone
devs are working on it.
I thought it worked like this - the openstack cli will infer from the
arguments if it should do v2 or v3 auth. In the above case for v3,
since you specify the username/password, osc knows it has to use
password auth (as opposed to token auth), and since all of the required
v3 arguments are provided (v3 api version, domains for user/project), it
can use v3 password auth. It knows it has to use the "/v3/auth/token"
path to get a token.
Similarly for v2, since it only has username/password, no v3 api or v3
domain arguments, it knows it has to use v2 password auth. It knows it
has to use "/v2.0/token" to get a token.
With the puppet-keystone code, since it uses TOKEN/URL, osc cannot infer
if it can use v2 or v3, so it requires the "/v2.0" or "/v3" suffix, and
the api version.
2 - openstackclient should be able to interpret v3 requests and append
"v3/" to OS_AUTH_URL=http://keystone-server.5000/ or rewrite the URL
if it is set as
OS_AUTH_URL=<http://keystone-server.5000/>http://keystone-server.5000/
It does, if it can determine from the given authentication arguments if
it can do v3 or v2.0.
It effectively does, again, assuming the path doesn't contain a version
number (x.x.x.x:5000)
3 - All deployments require /etc/keystone/keystone.conf with a token
(and not simply use openrc for creating additional endpoints, users,
etc beyond keystone itself and an admin user)
No. What I said about this issue was "Most people using
puppet-keystone, and realizing Keystone resources on nodes that are not
the Keystone node, put a /etc/keystone/keystone.conf on that node with
the admin_token in it."
That doesn't mean the deployment requires /etc/keystone/keystone.conf.
It should be possible to realize Keystone resources on non-Keystone
nodes by using ENV or openrc or other means.
Agreed. Also keystone.conf is used only to bootstrap keystone
installation and create admin users, etc.
I believe it should be possible to set v2.0 keystone OS_AUTH_URL in
openrc and puppet-keystone + puppet-openstacklib should be able to
make v3 requests sensibly by manipulating the URL.
Yes. Because for the puppet-keystone resource providers, they are coded
to a specific version of the api, and therefore need to be able to
set/override the OS_IDENTITY_API_VERSION and the version suffix in the URL.
No. To support V2 and V3, the OS_AUTH_URL must not contain any version
in order.
The less we deal with the version number the better!
Additionally, creating endpoints/users/roles shouldbe possible via
openrc alone.
Yes.
Yes, the openrc variables are used, if not available then the service
token from the keystone.conf is used.
It's not possible to write single node tests that can demonstrate this
functionality, which is why it probably went undetected for so long.
And since this is supported, we need tests for this.
I'm not sure what's the issue besides the fact keystone_puppet doesn't
generate a RC file once the admin user has been created. That is left to
be done by the composition layer. Although we might want to integrate that.
If that issue persists, assuming the AUTH_URL is free for a version
number and having an openrc in place, we're going to need a bug number
to track the investigation.
If anyone can speak up on these items, it could help influence the
outcome of this patch.
Thank you for your time.
Best Regards,
Matthew Mosesohn
Thanks,
Gilles
On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson <rmegg...@redhat.com
<mailto:rmegg...@redhat.com>> wrote:
On 07/31/2015 07:18 AM, Matthew Mosesohn wrote:
Jesse, thanks for raising this. Like you, I should just track
upstream
and wait for full V3 support.
I've taken the quickest approach and written fixes to
puppet-openstacklib and puppet-keystone:
https://review.openstack.org/#/c/207873/
https://review.openstack.org/#/c/207890/
and again to Fuel-Library:
https://review.openstack.org/#/c/207548/1
I greatly appreciate the quick support from the community to
find an
appropriate solution. Looks like I'm just using a weird edge case
where we're creating users on a separate node from where
keystone is
installed and it never got thoroughly tested, but I'm happy to fix
bugs where I can.
Most puppet deployments either realize all keystone resources on
the keystone node, or drop an /etc/keystone/keystone.conf with
admin token onto non-keystone nodes where additional keystone
resources need to be realized.
-Matthew
On Fri, Jul 31, 2015 at 3:54 PM, Jesse Pretorius
<jesse.pretor...@gmail.com <mailto:jesse.pretor...@gmail.com>>
wrote:
With regards to converting all services to use Keystone v3
endpoints, note
the following:
1) swift-dispersion currently does not support consuming
Keystone v3
endpoints [1]. There is a patch merged to master [2] to
fix that, but a
backport to kilo is yet to be done.
2) Each type (internal, admin, public) of endpoint created
with the Keystone
v3 API has its own unique id, unlike with the v2 API where
they're all
created with a single ID. This results in the keystone
client being unable
to read the catalog created via the v3 API when querying
via the v2 API. The
solution is to use the openstack client and to use the v3
API but this
obviously needs to be noted for upgrade impact and operators.
3) When glance is setup to use swift as a back-end,
glance_store is unable
to authenticate to swift when the endpoint it uses is a v3
endpoint. There
is a review to master in progress [3] to fix this which is
unlikely to make
it into kilo.
We (the openstack-ansible/os-ansible-deployment project)
are tracking these
issues and doing tests to figure out all the bits. These
are the bugs we've
hit so far. Also note that there is a WIP patch to gate
purely on Keystone
v3 API's which is planned to become voting (hopefully) by
the end of this
cycle.
[1] https://bugs.launchpad.net/swift/+bug/1468374
[2] https://review.openstack.org/195131
[3] https://review.openstack.org/193422
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://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://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://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
__________________________________________________________________________
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
