<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 1, 2014 at 12:33 PM, Anne Gentle <span dir="ltr"><<a href="mailto:anne@openstack.org" target="_blank">anne@openstack.org</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"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">
<div class="im">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><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 class="im">
<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><div>I'd like to understand the ramifications of <a href="https://review.openstack.org/#/c/62801/" target="_blank">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></div></div></div></blockquote><div><br>
</div><div>Yes, because they can discover the versioned API endpoint they need at runtime (which may differ from that required by another identity client), rather than requiring additional external configuration (or adding further bloat to the service catalog; every service that's overloading the service type with versioning is doing it *terribly* wrong).</div>
<div><br></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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<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></div></div></div></blockquote><div><br></div><div>Sure!</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">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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" target="_blank">http://eavesdrop.openstack.org/meetings/project/2014/project.2014-01-14-21.02.log.html</a></div>
</div><div class="im"><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" target="_blank">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></div><br></div></div>
<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>
<br></blockquote></div><br></div></div>