Open Stack

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?

> 
> So we really need version discovery rationalized once and for all,
> otherwise this nightmare goes far beyond something that's fixable within
> software that we control.
> 
> 	-Sean
> 
> -- 
> Sean Dague
> Samsung Research America
> sean at dague.net / sean.dague at samsung.com
> http://dague.net
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev