<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
The idea is that services can provide two resources:
<div><br>
</div>
<div>1. One resource provides a list of available versions of the service (Versions List)</div>
<div>2. One resource provides details about a particular version (Version Details)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>For the nova API see examples 3.26 - 3.33 here: <a href="http://docs.openstack.org/api/openstack-compute/2/content/Versions-d1e1193.html">http://docs.openstack.org/api/openstack-compute/2/content/Versions-d1e1193.html</a></div>
<div><br>
</div>
<div>-jOrGe W.</div>
<div><br>
</div>
<div><br>
<div>
<div>On Jan 28, 2013, at 2:21 PM, Dolph Mathews wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">
<div style="">I just noticed that we overlooked/forgot a feature from the v2 serviceCatalog API which includes the following attributes on each endpoint:</div>
<div><br>
</div>
<div> "versionId": "1.0",</div>
<div> "versionList": "<a href="https://compute.north.host/">https://compute.north.host/</a>",</div>
<div> "versionInfo": "<a href="https://compute.north.host/v1.0/">https://compute.north.host/v1.0/</a>",</div>
<div>
<div><br>
</div>
<div style="">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.</div>
<div style=""><br>
</div>
<div style="">Is anyone using this feature in v2 and want to see it carried forward to v3?</div>
<div><br>
</div>
-Dolph</div>
</div>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br>
</blockquote>
</div>
<br>
</div>
</body>
</html>