Open Stack

The idea is that services can provide two resources:

1.  One resource provides a list of available versions of the service (Versions List)
2.  One resource  provides details about a particular version (Version Details)

The idea was that the service catalog can give you a couple of pointers where you can get metadata about the service.  For example:  is  it in Beta?  When was it last updated? Are any new versions available? Where can I find documentation? etc.

For the nova API see examples 3.26 - 3.33 here: http://docs.openstack.org/api/openstack-compute/2/content/Versions-d1e1193.html

-jOrGe W.


On Jan 28, 2013, at 2:21 PM, Dolph Mathews wrote:

I just noticed that we overlooked/forgot a feature from the v2 serviceCatalog API which includes the following attributes on each endpoint:

  "versionId": "1.0",
  "versionList": "https://compute.north.host/",
  "versionInfo": "https://compute.north.host/v1.0/",

I never completely understood the intended use case for these attributes... e.g. if you can ask the remote service for a 'version list' then why does keystone need to redundantly identify the API version of the endpoint and enumerate options for each API version? I don't think you should have to revise your service catalog to roll out a new API version, either. IMO, clients should (ideally) start with an unversioned endpoint, receive a 300 Multiple Choice response, and select a compatible/acceptable versioned endpoint before proceeding.

Is anyone using this feature in v2 and want to see it carried forward to v3?

-Dolph
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto: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/20130128/0ecfbddb/attachment.html>