<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/10/2015 07:46 AM, Matthew
Mosesohn wrote:<br>
</div>
<blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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
moz-do-not-send="true" href="http://keystone-server:5000/"><a class="moz-txt-link-freetext" href="http://keystone-server:5000/">http://keystone-server:5000/</a></a><br>
</div>
</div>
</blockquote>
<br>
I don't think so. Keystone requires the version suffix "/v2.0" or
"/v3".<br>
<br>
<blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>2 - openstackclient should be able to interpret v3 requests
and append "v3/" to OS_AUTH_URL=<a moz-do-not-send="true"
href="http://keystone-server.5000/">http://keystone-server.5000/</a>
or rewrite the URL if it is set as OS_AUTH_URL=<a
moz-do-not-send="true" href="http://keystone-server.5000/"><a class="moz-txt-link-freetext" href="http://keystone-server.5000/">http://keystone-server.5000/</a></a><br>
</div>
</div>
</blockquote>
<br>
It does, if it can determine from the given authentication arguments
if it can do v3 or v2.0.<br>
<br>
<blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</div>
</div>
</blockquote>
<br>
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."<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><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>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Additionally, creating endpoints/users/roles shouldbe
possible via openrc alone.</div>
</div>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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>
</div>
</div>
</blockquote>
<br>
And since this is supported, we need tests for this.<br>
<blockquote
cite="mid:CA+CvLD6_7SBkLuJ_erK0UiRMiRwMDvnds14TdmkN3WUttSZGvQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://review.openstack.org/#/c/207873/"
rel="noreferrer" target="_blank">https://review.openstack.org/#/c/207873/</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://bugs.launchpad.net/swift/+bug/1468374"
rel="noreferrer" target="_blank">https://bugs.launchpad.net/swift/+bug/1468374</a><br>
[2] <a moz-do-not-send="true"
href="https://review.openstack.org/195131"
rel="noreferrer" target="_blank">https://review.openstack.org/195131</a><br>
[3] <a moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>