<div dir="ltr"><div><div><div>Sorry to everyone for bringing up this old thread, but it seems we may need more openstackclient/keystone experts to settle this.<br><br></div>I'm referring to the comments in <a href="https://review.openstack.org/#/c/207873/">https://review.openstack.org/#/c/207873/</a><br></div>Specifically comments from Richard Megginson and Gilles Dubreuil indicating openstackclient behavior for v3 keystone API.<br><br><br></div><div>A few items seem to be under dispute:<br></div><div>1 - Keystone should be able to accept v3 requests at <a href="http://keystone-server:5000/">http://keystone-server:5000/</a><br></div><div>2 - openstackclient should be able to interpret v3 requests and append "v3/" to OS_AUTH_URL=<a href="http://keystone-server.5000/">http://keystone-server.5000/</a> or rewrite the URL if it is set as OS_AUTH_URL=<a href="http://keystone-server.5000/">http://keystone-server.5000/</a><br></div><div>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)<br><br></div><div>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.<br></div><div>Additionally, creating endpoints/users/roles shouldbe possible via openrc alone. It's not possible to write single node tests that can demonstrate this functionality, which is why it probably went undetected for so long.<br><br></div><div>If anyone can speak up on these items, it could help influence the outcome of this patch. <br><br></div><div>Thank you for your time.<br><br></div><div>Best Regards,<br></div><div>Matthew Mosesohn<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 31, 2015 at 6:32 PM, Rich Megginson <span dir="ltr"><<a href="mailto:rmeggins@redhat.com" target="_blank">rmeggins@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 07/31/2015 07:18 AM, Matthew Mosesohn wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Jesse, thanks for raising this. Like you, I should just track upstream<br>
and wait for full V3 support.<br>
<br>
I've taken the quickest approach and written fixes to<br>
puppet-openstacklib and puppet-keystone:<br>
<a href="https://review.openstack.org/#/c/207873/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/207873/</a><br>
<a href="https://review.openstack.org/#/c/207890/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/207890/</a><br>
<br>
and again to Fuel-Library:<br>
<a href="https://review.openstack.org/#/c/207548/1" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/207548/1</a><br>
<br>
I greatly appreciate the quick support from the community to find an<br>
appropriate solution. Looks like I'm just using a weird edge case<br>
where we're creating users on a separate node from where keystone is<br>
installed and it never got thoroughly tested, but I'm happy to fix<br>
bugs where I can.<br>
</blockquote>
<br></span>
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.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-Matthew<br>
<br>
On Fri, Jul 31, 2015 at 3:54 PM, Jesse Pretorius<br>
<<a href="mailto:jesse.pretorius@gmail.com" target="_blank">jesse.pretorius@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With regards to converting all services to use Keystone v3 endpoints, note<br>
the following:<br>
<br>
1) swift-dispersion currently does not support consuming Keystone v3<br>
endpoints [1]. There is a patch merged to master [2] to fix that, but a<br>
backport to kilo is yet to be done.<br>
2) Each type (internal, admin, public) of endpoint created with the Keystone<br>
v3 API has its own unique id, unlike with the v2 API where they're all<br>
created with a single ID. This results in the keystone client being unable<br>
to read the catalog created via the v3 API when querying via the v2 API. The<br>
solution is to use the openstack client and to use the v3 API but this<br>
obviously needs to be noted for upgrade impact and operators.<br>
3) When glance is setup to use swift as a back-end, glance_store is unable<br>
to authenticate to swift when the endpoint it uses is a v3 endpoint. There<br>
is a review to master in progress [3] to fix this which is unlikely to make<br>
it into kilo.<br>
<br>
We (the openstack-ansible/os-ansible-deployment project) are tracking these<br>
issues and doing tests to figure out all the bits. These are the bugs we've<br>
hit so far. Also note that there is a WIP patch to gate purely on Keystone<br>
v3 API's which is planned to become voting (hopefully) by the end of this<br>
cycle.<br>
<br>
[1] <a href="https://bugs.launchpad.net/swift/+bug/1468374" rel="noreferrer" target="_blank">https://bugs.launchpad.net/swift/+bug/1468374</a><br>
[2] <a href="https://review.openstack.org/195131" rel="noreferrer" target="_blank">https://review.openstack.org/195131</a><br>
[3] <a href="https://review.openstack.org/193422" rel="noreferrer" target="_blank">https://review.openstack.org/193422</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>