Open Stack

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130430/124c5dfd/attachment.html>