<div dir="ltr">It would really be nice to be able to hit an endpoint like <a href="https://hostname:35357/">https://hostname:35357/</a> and get a list of available versions back. It would make discovery easier.<br><br>But, for scripting languages like PHP this would add a lot of extra http requests unless you cache the location between page views/requests. We'd need to be smart about it. I would mind the "both and" approach. if /v3 is appended it's smart enough in an SDK to know what to do. If it's not there it's smart enough to hit the top level where a list might be available of what's supported.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 4, 2014 at 2:55 PM, Jesse Noller <span dir="ltr"><<a href="mailto:jesse.noller@rackspace.com" target="_blank">jesse.noller@rackspace.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="HOEnZb"><div class="h5"><br>
On Feb 4, 2014, at 1:28 PM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
<br>
> On 02/05/2014 01:50 AM, Jesse Noller wrote:<br>
>><br>
>> On Feb 4, 2014, at 10:31 AM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br>
>><br>
>>> On 02/05/2014 01:09 AM, Dean Troyer wrote:<br>
>>>> On Tue, Feb 4, 2014 at 9:00 AM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a><br>
>>>> <mailto:<a href="mailto:sean@dague.net">sean@dague.net</a>>> wrote:<br>
>>>><br>
>>>>   Can you be more specific about what goes wrong here? I'm not entirely<br>
>>>>   sure I understand why an old client of arbitrary age needs to be<br>
>>>>   supported with new OpenStack. The contract is the API, not the client,<br>
>>>>   and an old client that doesn't do version discovery is just a buggy<br>
>>>>   client from what I'm concerned. Time to release a new version.<br>
>>>><br>
>>>><br>
>>>> Problem 1: API version discovery is not universally considered to be<br>
>>>> part of the API and therefore is not defined by most services beyond<br>
>>>> them responding to a '/' request with a 300 response and a list of<br>
>>>> versions. No two of these responses look alike except where the source<br>
>>>> was copied from an existing service.<br>
>>>><br>
>>>> Problem 2: Identity is unique in that it is handed a deployment-defined<br>
>>>> URL to authenticate and get endpoints for all other services.  Most of<br>
>>>> these auth URLs have a version hard-coded in them because the client<br>
>>>> didn't do version discovery or negotiation until recently.  This is what<br>
>>>> we're talking about here, how to remove the version from this URL and<br>
>>>> not break old clients.  We can't.  Not without doing nasty things like<br>
>>>> detecting an old client and compensating for it server-side.  So we have<br>
>>>> to work out a way for new clients to do discovery even when handed a URL<br>
>>>> that has a version in it.<br>
>>>><br>
>>>> I've tested a couple of more generalized approaches, and the best<br>
>>>> solution I have found so far is to simply special-case the known legacy<br>
>>>> behaviour then drop in to the general discovery process.<br>
>>>><br>
>>>>   I also wonder if this is an issue with version discovery implementation.<br>
>>>>   It seems like if we think this is going to be affecting multiple<br>
>>>>   services before doing an odd hack for keystone, we should actually<br>
>>>>   figure out a pattern that works for all services, and figure out why<br>
>>>>   this has only just become an issue. Most of the other services have done<br>
>>>><br>
>>>><br>
>>>> The services that traditionally embed a version inside the URL followed<br>
>>>> by a tenant ID or something get even deeper into parsing the URL to hack<br>
>>>> the version.<br>
>>>><br>
>>>>   dual APIs at some point over the last 2 years, and this didn't seem to<br>
>>>>   trip them up too badly. What happened differently in keystone that made<br>
>>>>   this an issue? And what can be learned about how we structure APIs going<br>
>>>>   forward.<br>
>>>><br>
>>>><br>
>>>> I think the difference is this is the first API we have actually tried<br>
>>>> to deprecate and we don't have the option to hide it in an updated SC<br>
>>>> endpoint.  The service catalog has hidden a lot of this pain for other<br>
>>>> services because the clients generally can use whatever endpoint the SC<br>
>>>> gives it.<br>
>>>><br>
>>>><br>
>>>> a) Version discovery needs to be rationalized across the services.<br>
>>>> We've talked about this at summits before, and proposals have been<br>
>>>> written.  And here we are.  We'll do it again in Atlanta, hopefully for<br>
>>>> the last time.<br>
>>>><br>
>>>> b) Define a common structured endpoint and let the client assemble the<br>
>>>> components into the final URL.  If the service catalog had a base URL<br>
>>>> for compute, and a list of versions, and the additional bits to be<br>
>>>> appended the client could make an intelligent choice and assemble the<br>
>>>> endpoint.  It isn't like the client doesn't already have to know how the<br>
>>>> REST URLs are constructed.<br>
>>>><br>
>>>> b-alt) Stop putting things like tenant IDs in the SC.  This has the same<br>
>>>> issue as the auth URL in how to do this without instantly breaking the<br>
>>>> existing clients.<br>
>>><br>
>>> Ok, much clearer now to me (though I'll still claim jetlag for some bits<br>
>>> not sinking in).<br>
>>><br>
>>> I think a really important thing to keep in mind is any solution that's<br>
>>> implemented client side, is something that all the other OpenStack SDKs<br>
>>> are going to have to implement as well. So an ugly hack isn't just<br>
>>> python-keystone... and be done. It's also just hoisted doing that ugly<br>
>>> hack on the php / go sdk teams, jclouds, deltacloud, etc. Something they<br>
>>> may not be aware is going to break them, or their users.<br>
>><br>
>> Do we have official openstack PHP / go SDKs?<br>
><br>
> Official is a strong word, but we do have stackforge teams active on it:<br>
> * <a href="https://github.com/stackforge/openstack-sdk-php" target="_blank">https://github.com/stackforge/openstack-sdk-php</a><br>
> * <a href="https://github.com/stackforge/golang-client" target="_blank">https://github.com/stackforge/golang-client</a><br>
><br>
> And I think we should should be mindful of their work to make OpenStack<br>
> easily accessible from their language communities.<br>
<br>
<br>
</div></div>Oh for sure - but I was wondering because there’s also:<br>
<br>
jclouds (java): <a href="http://jclouds.apache.org/" target="_blank">http://jclouds.apache.org/</a><br>
<br>
php-opencloud (php): <a href="https://github.com/rackspace/php-opencloud" target="_blank">https://github.com/rackspace/php-opencloud</a><br>
<br>
fog (ruby): <a href="http://fog.io/" target="_blank">http://fog.io/</a><br>
<br>
libcloud (python):  <a href="http://libcloud.apache.org/" target="_blank">http://libcloud.apache.org/</a><br>
<br>
gophercloud (go): <a href="https://github.com/rackspace/gophercloud" target="_blank">https://github.com/rackspace/gophercloud</a><br>
<br>
openstack .net (.net): <a href="https://github.com/rackspace/openstack.net" target="_blank">https://github.com/rackspace/openstack.net</a><br>
<br>
So finding a go client and php one one stackforge is surprising - wondering if we can combine efforts - on my end I have full time people staffing *just* the client-side SDKs across all of these. So yes - we are sensitive to API changes.<br>

<span class="HOEnZb"><font color="#888888"><br>
Jesse<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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></div>