Open Stack

On Fri, Apr 26, 2013 at 4:20 PM, Gabriel Hurley
<Gabriel.Hurley at nebula.com> wrote:
>     1. Treat the Service Catalog's version choice as the "preferred" API version and just go with it.

In theory this is what the operator is telling you (client) to do so
that's what you should do.  :)

>     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.

This would mean parsing the endpoints to verify or change the version.
 Putting context information (eg project IDs) into the service catalog
doesn't seem like such a good idea to me any more without having the
components to properly re-build the endpoint available.

It actually wouldn't be too hard to identify the list of known version
strings in the path but I think that should only be a
backward-compatibility option and not used going forward.  In fact,
we'll probably wind up doing this no matter what the future direction
is.

>     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.

Or break the endpoints down by API version and teach the client how to
assemble an endpoint for the desired version.


4. Client lib queries the '/' route to get the supported API versions
and selects one.  Service catalog endpoints do not contain a version,
but still contain the context info as required.  We can reliably
identify the root of the URL path and insert the version there as
required.  I don't think there are any routes that have an API version
other than as the first component.

dt

--

Dean Troyer
dtroyer at gmail.com