Open Stack

On Tue, Apr 30, 2013 at 8:09 PM, Gabriel Hurley
<Gabriel.Hurley at nebula.com>wrote:

>  I’m on board with almost all those points.****
>
> ** **
>
> 1: check, should be the default, and what we do in devstack.****
>
> ** **
>
> 2: check.****
>
> ** **
>
> 3: check, though I think you should have to pass in something explicit to
> say “use this endpoint as is.” I don’t want to be guessing at “does this
> URL contain a version?”
>

Rather than guessing, I think the client should GET whatever endpoint it's
given, and figure out what's there (is it the root of the service? is it a
versioned endpoint? do I even understand the response?)


> ****
>
> ** **
>
> 4: check.****
>
> ** **
>
> 5: check.****
>
> ** **
>
> 6: (about project ids in urls) The argument in favor of them (passed to me
> by some of the original Nova devs) is that by the strictest definition, to
> be RESTful an API can’t change its URL structure based on context, so any
> context which can alter the response has to go in the URL.
>

Agree.


> Personally I think this is an impractical requirement and most modern
> RESTful APIs have completely thrown out this notion. I’m 100% in favor of
> eliminating the practice in OpenStack, but it would require a significant
> deprecation process.
>

For the sake of getting expected behavior out of intermediate caching, I
think it's a practical requirement.

In the meantime I think the clients should know if a project ID belongs in
> the URL and should be capable of constructing those URLs themselves from
> the root service endpoint contained in the catalog.
>

Big +1, it should be a client-side issue.


> ****
>
> ** **
>
> I’ll have a formal proposal for all this in the next couple days,****
>
> ** **
>
> **-          **Gabriel****
>
> ** **
>
> *From:* Dolph Mathews [mailto:dolph.mathews at gmail.com]
> *Sent:* Tuesday, April 30, 2013 3:27 PM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] Keystone Service Catalog endpoints vs. API
> versions****
>
> ** **
>
> Some constraints to solving this problem that I've had on my mind... given
> that we need to continue to support *versioned* endpoints being provided by
> the catalog, clients should:****
>
> ** **
>
> 1) be configurable with an unversioned URL, and automatically work with
> the client's preferred API version (preferred being highest client-server
> compatible API, using 'stable' endpoints before anything else).****
>
> ** **
>
> 2) be configurable with an unversioned URL and a major version specifier
> (e.g. client.Client(..., version=3), and forcibly work with that API
> version (e.g. /v3/ or /v3.1/ or whatever) if it's available****
>
> ** **
>
> 3) be configurable with a versioned URL, and forcibly use the API
> available at that endpoint****
>
> ** **
>
> 4) if the best match is not marked as "stable", then the client should
> raise a warning to the user****
>
> ** **
>
> 5) if the only match is not available (e.g. very old client vs very new
> service), then the client should abort gracefully****
>
> ** **
>
> The above completely ignores the issue of tenant/project-specific
> endpoints, which is a concept I'm not a huge fan of, as it seems like
> context that auth_token middleware should be able to sufficiently
> provide... so, there's surely some issue there I'm not considering.****
>
>
> ****
>
> ** **
>
> -Dolph****
>
> ** **
>
> On Fri, Apr 26, 2013 at 9:58 PM, Dolph Mathews <dolph.mathews at gmail.com>
> wrote:****
>
> +1; ideally the service catalog should not contain any versioned endpoints.
> ****
>
> ** **
>
> -Dolph****
>
> ** **
>
> On Fri, Apr 26, 2013 at 5:05 PM, Brian Waldon <bcwaldon at gmail.com> wrote:*
> ***
>
> Keystone should not have any versions in its service catalog endpoints as
> version publication and negotiation belongs to the service itself. Your
> third option is the solution to the core problem here. And to be clear, in
> addition to the host/port, the endpoints should also be able to define a
> base path.****
>
>
>
> On Apr 26, 2013, at 2:20 PM, Gabriel Hurley wrote:
>
> > I've been working on API version selection in Horizon and came to an odd
> realization:
> >
> > Keystone's service catalog can (and in the case of devstack currently
> does) send out an endpoint for a version which is not the latest stable
> API. In this case we have the Keystone v3 API, but devstack sets the
> Keystone SC entry to v2.
> >
> > This leaves me with three options:
> >
> >    1. Treat the Service Catalog's version choice as the "preferred" API
> version and just go with it.
> >    2. Treat the Service Catalog as a "suggested" version but query the
> root of the API to see if there's a different version which Horizon would
> prefer.
> >    3. Rewrite/redefine the service catalog so that it only returns the
> hosts/ports for the services. This would require a lot of reworking in the
> clients, too.
> >
> > I'm interested in input from the community; option 1 is the easiest,
> option 2 solves the problem for me, and option 3 is superior insofar as
> allowing flexible version choosing based on the what the consumer is able
> to handle but requires the most work.
> >
> > Thoughts?
> >
> >    - Gabriel
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev****
>
> ** **
>
> ** **
>
> _______________________________________________
> 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/20130501/044023ee/attachment.html>