Excerpts from Jesse Noller's message of 2014-02-04 11:55:57 -0800: > > On Feb 4, 2014, at 1:28 PM, Sean Dague <s...@dague.net> wrote: > > > On 02/05/2014 01:50 AM, Jesse Noller wrote: > >> > >> 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? > > > > 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
And goose https://launchpad.net/goose > > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
