[openstack-dev] Keystone Service Catalog endpoints vs. API versions
dolph.mathews at gmail.com
Sat Apr 27 02:58:00 UTC 2013
+1; ideally the service catalog should not contain any versioned endpoints.
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
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev