Open Stack

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.

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
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.

	-Sean

On 02/04/2014 04:50 AM, Adam Young wrote:
> We have to support old clients.
>
> Old clients expect that the URL that comes back for the service catalog
> has the version in it.
> Old clients don't do version negotiation.
> 
> Thus, we need an approach to not-break old clients while we politely
> encourage the rest of the world to move to later APIs.
> 
> 
> I know Keystone has this problem.  I've heard that some of the other
> services do as well.  Here is what I propose.  It is ugly, but it is a
> transition plan, and can be disabled once the old clients are deprecated:
> 
> HACK:  In a new client, look at the URL.  If it ends with /v2.0, chop it
> off and us the substring up to that point.
> 
> Now, at this point you are probably going:  That is ugly, is it really
> necessary?  Can't we do something more correct?
> 
> No.  I mean, we are already doing something more correct in that the
> later versions of the Keystone client already support version
> discovery.  The problem is that older clients don't.
> 
> Alternatives:
> 
> 1.  Just chop the url.  Now only clients smart enough to do negotiation
> work. Older clients no longer work.  Suck it up.
> 2.  Put multiple endpoints in the service catalog.  Ugh.  Now we've just
> doubled the size of the service catalog, and we need new logic to get
> the identityv3 endpoints, cuz we need to leave "identity" endpoints for
> existing clients.
> 3. Do some sort of magic on the server side to figure out the right URL
> to respond to the client request.  This kind of magic was banned under
> the wizarding convention of '89.
> 
> 
> Can we accept that this is necessary, and vow to never let this happen
> again by removing the versions from the URLs after the current set of
> clients are deprecated?
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140205/4439c224/attachment.pgp>