<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 24, 2013 at 12:41 AM, Jamie Lennox <span dir="ltr"><<a href="mailto:jlennox@redhat.com" target="_blank">jlennox@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, 2013-05-02 at 00:46 +0000, Gabriel Hurley wrote:<br>
</div><div class="im">> Based on input from several of the PTLs (and others), I'd like to propose the following outline for how version discovery should be handled across heterogeneous clouds:<br>
><br>
> <a href="https://etherpad.openstack.org/api-version-discovery-proposal" target="_blank">https://etherpad.openstack.org/api-version-discovery-proposal</a><br>
><br>
> Further discussion is absolutely welcome, and I would like to propose it as a topic for review by the Technical Committee at the next meeting since it involves a significant cross-project standardization effort.<br>
><br>
> All the best,<br>
><br>
> - Gabriel<br>
<br>
</div>So I started on this somewhat independently before i found the blueprint<br>
and given I have a semi working implementation i've got a few questions<br>
or essentially an area i find inconsistent.<br>
<br>
AFAIK there are no other serious attempts at this so i've got nothing to<br>
go off. Also for the time being I don't care about HATEOS, or future<br>
discovery protocols, just getting something that works for keystone now.<br>
<br>
I think the way version is treated in the current blueprint is off.<br>
Looking at 'Auth with a Specified Version' point 2 says that we should<br>
not infer the version from the URL and point 3 says that if i provide a<br>
version number with a non-versioned endpoint to retrieve possible<br>
versions and instantiate a client if an endpoint is available for that<br>
version.<br>
<br>
I don't think that we should be checking the url for what is and what<br>
isn't a versioned endpoint for the same reasons we shouldn't be<br>
retrieving the version from the URL.<br>
<br>
What i would like to do is treat the version parameter as the requested<br>
version, rather than using it to prevent a lookup for versions. What<br>
this means is that i can say:<br>
client.Client(auth_url="<a href="http://example.com:5000/" target="_blank">http://example.com:5000/</a>", user=foo,<br>
version=2.0, ...)<br>
and retrieve a version 2 client from a provider that may provide both<br>
versions v2 & v3. This will still require a lookup of the auth_url even<br>
though version is specified.<br></blockquote><div><br></div><div>I believe this is exactly what the document is trying to convey (I don't think it's advocating skipping the multiple choice response).</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Keystone (not sure on others) provides version information at GET /v2.0<br>
(and other versions) as well as GET / so if i say:<br>
client.Client(endpoint="<a href="http://example.com:5000/v2.0" target="_blank">http://example.com:5000/v2.0</a>",<br>
version=2.0, token=foo)<br>
It should be validated that the endpoint is capable of using the V2 api<br>
and doing:<br>
client.Client(endpoint="<a href="http://example.com:5000/v2.0" target="_blank">http://example.com:5000/v2.0</a>",<br>
version=3.0, token=foo)<br>
should fail immediately.<br></blockquote><div><br></div><div>+1 to both</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To summarize: every call to client.Client should result in a query to<br>
check available versions. The version parameter is an indicator of what<br>
version client should be retrieved from those specified as available and<br>
it should fail if it can't deliver. If you _really_ want to use a<br>
particular client without a lookup you should use the original<br>
keystoneclient.v2_0.Client which is what is returned from a successful<br>
client.Client (with version=2) call anyway and takes the same<br>
parameters.<br>
<br>
I've posted the work for review: <a href="https://review.openstack.org/#/c/38414/" target="_blank">https://review.openstack.org/#/c/38414/</a><br>
and would appreciate comments/clarification.<br>
<br>
<br>
Thanks,<br>
<br>
Jamie<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<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>
<br>
<br>
<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>