OMG, table of contents on the API reference site is SO MUCH BETTER! :) Good to know about the Launchpad for the site. Didn't know about that one.
- Gabriel From: annegen...@justwriteclick.com [mailto:annegen...@justwriteclick.com] On Behalf Of Anne Gentle Sent: Thursday, May 09, 2013 7:41 AM To: Gabriel Hurley Cc: Devendra Gupta; openstack@lists.launchpad.net Subject: Re: [Openstack] API version in Grizzly On Wed, May 8, 2013 at 6:57 PM, Gabriel Hurley <gabriel.hur...@nebula.com<mailto:gabriel.hur...@nebula.com>> wrote: In Grizzly I can send Keystone requests to either http://<keystone_host>:5000/v2.0/<http://%3ckeystone_host%3e:5000/v2.0/> or to http://<keystone_host>:5000/v3/<http://%3ckeystone_host%3e:5000/v3/> and both work just fine (provided I send the right request). Both APIs are enabled, and simply have different API controllers wired to different code paths under the hood. The only thing making one "default" is the fact that DevStack (and by extension a lot of guides and a lot of people's existing copy-pasted installations) have the Keystone v2.0 endpoint hard-coded into the service catalog. See the various threads and my TC proposal for further detail on what I think about that fact and what to do with it going forward. Okay, thanks for this explanation. Keystone team, this does not feel well documented. Let's come up with a plan for further explaining that in the docs. As for api.openstack.org<http://api.openstack.org>, I always look at the "Complete Reference" (http://api.openstack.org/api-ref.html) which lists one version for each service API (currently still Keystone v2.0). As long as you're taking feature requests, what I'd *like* to see when I land on that page is a collapsed list of each service API type (e.g. Identity, Compute, etc.) which I can then expand, revealing the list of available versions. Expanding one of those should yield what I currently see on the Complete Reference page. :) Good news, we have a new floating TOC and version labels that helps us go towards documenting all versions on the reference page as well. See http://api.openstack.org/api-ref.html. Ideally when you have ideas and needs like this you'll log a bug or blueprint at http://bugs.launchpad.net/openstack-api-site. Anne All the best, * Gabriel From: annegen...@justwriteclick.com<mailto:annegen...@justwriteclick.com> [mailto:annegen...@justwriteclick.com] On Behalf Of Anne Gentle Sent: Wednesday, May 08, 2013 4:38 PM To: Gabriel Hurley Cc: Devendra Gupta; openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> Subject: Re: [Openstack] API version in Grizzly On Wed, May 8, 2013 at 4:54 PM, Gabriel Hurley <gabriel.hur...@nebula.com<mailto:gabriel.hur...@nebula.com>> wrote: Identity service has both a v2.0 and v3 side-by-side. There isn't necessarily a "default" except for the fact that most people's Service Catalogs still say "v2.0" in them because they're hard-coded that way. Wow, really? I have asked and asked about that API in particular and still don't understand how that really works. Can you explain more about how that can happen other than mis-labeled endpoints? In the future I believe the api.openstack.org<http://api.openstack.org> site would gain a lot by storing documentation for each version of the API for historical purposes, legacy deployments, etc. Sure would help me, too. ;-) Could you explain more about what "storing documentation for each version of the API for historical purposes" would look like to you? We have all versions (v 1.1, v2, v3.0) of each API spec stored. Do you want them published as well? We do so for Image API for example. Tell me more. Anne - Gabriel From: Openstack [mailto:openstack-bounces+gabriel.hurley<mailto:openstack-bounces%2Bgabriel.hurley>=nebula....@lists.launchpad.net<mailto:nebula....@lists.launchpad.net>] On Behalf Of Anne Gentle Sent: Wednesday, May 08, 2013 2:44 PM To: Devendra Gupta Cc: openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> Subject: Re: [Openstack] API version in Grizzly Hi Devendra, Generally the guidance for the api.openstack.org<http://api.openstack.org> site is to publish documents that reflect the latest version, grizzly, as the underlying implementation for the API. However the cloud provider can pick and choose which extensions they have in place, for example, so some Compute extensions may be unavailable on essex for example. Generally I believe this list of API versions is true for Grizzly default implementations. PTLs please correct as needed: Identity Service API 2.0 Compute API 2 and Extensions Image Service API 2 (a provider could choose to implement v1) Object Storage API 1.0 Networking API 2.0 Block Storage Service API 2.0 Thanks, Anne On Wed, May 8, 2013 at 3:23 PM, Devendra Gupta <dev29...@gmail.com<mailto:dev29...@gmail.com>> wrote: Hi, I am trying to find the lasted stable API versions of all the OpenStack components, I am looking around in OpenStack docs but unable to see some specific page which says about particular version of APIs are available with Grizzly. I can see following pages but they don't say what version of API is latest stable with Grizzly. http://docs.openstack.org/api/api-specs.html http://api.openstack.org/api-ref.html I need this information to plan some work related to OpenStack, guidance around this would be highly appreciate. Thanks, Devendra _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
