[openstack-dev] [keystone] endpoint versioning in API v3

Jorge Williams jorge.williams at rackspace.com
Wed Jan 30 16:44:50 UTC 2013

The version id is part of the service catalog now -- I'd also vote to keep that in v3.

-jOrGe W.

On Jan 29, 2013, at 6:50 PM, Ali, Haneef wrote:

I agree with you. Just having an attribute version will help the UI.  Are we going to add this?


From: Jorge Williams [mailto:jorge.williams at rackspace.com]
Sent: Tuesday, January 29, 2013 9:54 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] endpoint versioning in API v3

On Jan 29, 2013, at 9:37 AM, Jay Pipes wrote:

I think versionList is pointless, as you mention above the proper way of
handling this is a 300 Multiple Choice response on the base endpoint.
The endpoints themselves should be the source of truth about what
versions of an API they expose or support. Keystone, IMHO, should merely
be a directory of endpoints/services, not a directory of endpoints and
API versions on an endpoint.

I'm sorry there seems to be some confusion about what the attributes are for.  I should have been more specific....

The purpose is *not* to have all version metadata reside in keystone. Keystone is simply worried about Endpoints as you've described.  These attributes are part of an endpoint and they   simply  provide two links to the service itself. One link provides a list of available versions for that service at that endpoint.  The other lists details about the version described by the endpoint.  Thad metadata likes in the service not in keystone.  The links allow a client  a means of introspecting what's available.  300 Multiple Choice response is fine -- and we should support that too, but sometimes you want to know what's out there without having to issue a working request to the service (create a server) -- this is useful especially if you need to create a UI, for example.  You shouldn't have to create a server to figure out if you support version X, and therefore should add version X features into the UI.

-jOrGe W.

OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130130/48cc4791/attachment.html>

More information about the OpenStack-dev mailing list