<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 23, 2014 at 5:21 AM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all,<br>
<br>
I've recently been working on migrating the heat internal interfaces to use<br>
the keystone v3 API exclusively[1].<br>
<br>
This work has mostly been going well, but I've hit a couple of issues which<br>
I wanted to discuss, so we agree the most appropriate workarounds:<br>
<br>
1. keystoneclient v3 functionality not accessible when catalog contains a<br>
v2 endppoint:<br>
<br>
In my test environment my keystone endpoint looks like:<br>
<br>
<a href="http://127.0.0.1:5000/v2.0" target="_blank">http://127.0.0.1:5000/v2.0</a><br>
<br>
And I'd guess this is similar to the majority of real deployments atm?<br>
<br></blockquote><div><br></div><div><div>Yes, I was just researching this for the Ops Guide O'Reilly edition, and don't see evidence of deployments doing otherwise in their endpoint definition. </div><div><br></div>
<div>Also I didn't uncover many (any?) deployments going from Identity v2 to v3 yet. Meaning, if they're already running v2, when they upgrade to havana, they do not move to Identity v3. </div></div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So when creating a keystoneclient object I've been doing:<br>
<br>
from keystoneclient.v3 import client as kc_v3<br>
v3_endpoint = self.context.auth_url.replace('v2.0', 'v3')<br>
client = kc_v3.Client(auth_url=v3_endpoint, ...<br>
<br>
Which, assuming the keystone service has both v2 and v3 API's enabled<br>
works, but any attempt to use v3 functionality fails with 404 because<br>
keystoneclient falls back to using the v2.0 endpoint from the catalog.<br>
<br>
So to work around this I do this:<br>
<br>
client = kc_v3.Client(auth_url=v3_endpoint, endpoint=v3_endpoint, ...<br>
client.authenticate()<br>
<br>
Which results in the v3 features working OK.<br>
<br>
So my questions are:<br>
- Is this a reasonable workaround for production environments?<br>
- What is the roadmap for moving keystone endpoints to be version agnostic?<br>
- Is there work ongoing to make the client smarter in terms of figuring out<br>
what URL to use (version negotiation or substituting the appropriate path<br>
when we are in an environment with a legacy v2.0 endpoint..)<br>
<br></blockquote><div><br></div><div><div>I'd like to understand the ramifications of <a href="https://review.openstack.org/#/c/62801/">https://review.openstack.org/#/c/62801/</a> so I have a few questions:</div><div>
<br></div><div>- If keystone service catalog endpoints become version agnostic, does that make other project's support of multiple versions of the Identity API easier?</div><div><br></div><div>- If the client gets smarter, does that automatically let Heat support Identity v2? Or is more work required in Heat after your blueprint at [1] is complete?</div>
<div><br></div><div>I saw a brief discussion at project meeting Jan 14 [3] but I didn't see any questioning of whether it's premature to preclude the use of Identity v2 in any integrated project. </div><div><br></div>
<div>Can we discuss implications and considerations at the project meeting next week? </div><div>Thanks,</div><div>Anne</div><div><br></div><div>[3] <a href="http://eavesdrop.openstack.org/meetings/project/2014/project.2014-01-14-21.02.log.html">http://eavesdrop.openstack.org/meetings/project/2014/project.2014-01-14-21.02.log.html</a></div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
2. Client (CLI) support for v3 API<br>
<br>
What is the status re porting keystoneclient to provide access to the v3<br>
functionality on the CLI?<br>
<br>
In particular, Heat is moving towards using domains to encapsulate the<br>
in-instance users it creates[2], so administrators will require some way to<br>
manage users in a non-default domain, e.g to get visibility of what Heat is<br>
doing in that domain and debug in the event of any issues.<br>
<br>
If anyone can provide any BP links or insight that would be much<br>
appreciated!<br>
<br>
Thanks,<br>
<br>
Steve<br>
<br>
[1] <a href="https://blueprints.launchpad.net/heat/+spec/keystone-v3-only" target="_blank">https://blueprints.launchpad.net/heat/+spec/keystone-v3-only</a><br>
[2] <a href="https://wiki.openstack.org/wiki/Heat/Blueprints/InstanceUsers" target="_blank">https://wiki.openstack.org/wiki/Heat/Blueprints/InstanceUsers</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>