On Feb 4, 2014, at 10:31 AM, Sean Dague <s...@dague.net> wrote: > On 02/05/2014 01:09 AM, Dean Troyer wrote: >> On Tue, Feb 4, 2014 at 9:00 AM, Sean Dague <s...@dague.net >> <mailto:s...@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 > s...@dague.net / sean.da...@samsung.com > http://dague.net > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
