On 02/05/2014 01:50 AM, Jesse Noller wrote: > > On Feb 4, 2014, at 10:31 AM, Sean Dague <[email protected]> wrote: > >> On 02/05/2014 01:09 AM, Dean Troyer wrote: >>> On Tue, Feb 4, 2014 at 9:00 AM, Sean Dague <[email protected] >>> <mailto:[email protected]>> 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. -Sean -- Sean Dague Samsung Research America [email protected] / [email protected] http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
