Open Stack

It would really be nice to be able to hit an endpoint like
https://hostname:35357/ and get a list of available versions back. It would
make discovery easier.

But, for scripting languages like PHP this would add a lot of extra http
requests unless you cache the location between page views/requests. We'd
need to be smart about it. I would mind the "both and" approach. if /v3 is
appended it's smart enough in an SDK to know what to do. If it's not there
it's smart enough to hit the top level where a list might be available of
what's supported.


On Tue, Feb 4, 2014 at 2:55 PM, Jesse Noller <jesse.noller at rackspace.com>wrote:

>
> On Feb 4, 2014, at 1:28 PM, Sean Dague <sean at dague.net> wrote:
>
> > On 02/05/2014 01:50 AM, Jesse Noller wrote:
> >>
> >> 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?
> >
> > 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
>
> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140204/0f18da12/attachment.html>