Open Stack

On Feb 4, 2014, at 1:28 PM, Sean Dague <sean at dague.net> wrote:

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


Oh for sure - but I was wondering because there’s also:

jclouds (java): http://jclouds.apache.org/ 

php-opencloud (php): https://github.com/rackspace/php-opencloud 

fog (ruby): http://fog.io/

libcloud (python):  http://libcloud.apache.org/

gophercloud (go): https://github.com/rackspace/gophercloud

openstack .net (.net): https://github.com/rackspace/openstack.net

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.

Jesse