On Wed, May 8, 2013 at 6:57 PM, Gabriel Hurley <gabriel.hur...@nebula.com>wrote:
> In Grizzly I can send Keystone requests to either *http://<keyston** > e_host>:5000/v2.0/* or to *http://<keystone_host>: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, I always look at the “Complete Reference” (* > http://api.openstack.org/api-ref.html*<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. J > > 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 <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 > > *Subject:* Re: [Openstack] API version in Grizzly > > > > On Wed, May 8, 2013 at 4:54 PM, Gabriel Hurley <*gabriel.hur...@nebula.com > * <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*<openstack-bounces%2Bgabriel.hurley> > =*nebula....@lists.launchpad.net* <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* <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*<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://docs.openstack.org/api/api-specs.html> > *http://api.openstack.org/api-ref.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*<https://launchpad.net/~openstack> > Post to : *openstack@lists.launchpad.net*<openstack@lists.launchpad.net> > Unsubscribe : > *https://launchpad.net/~openstack*<https://launchpad.net/~openstack> > More help : > *https://help.launchpad.net/ListHelp*<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
