openstack team mailing list archive

[Anne Gentle <anne@xxxxxxxxxxxxx>]

On Wed, May 8, 2013 at 6:57 PM, Gabriel Hurley <Gabriel.Hurley@xxxxxxxxxx>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:* annegentle@xxxxxxxxxxxxxxxxxx [
> mailto:annegentle@xxxxxxxxxxxxxxxxxx <annegentle@xxxxxxxxxxxxxxxxxx>] *On
> Behalf Of *Anne Gentle
> *Sent:* Wednesday, May 08, 2013 4:38 PM
> *To:* Gabriel Hurley
> *Cc:* Devendra Gupta; openstack@xxxxxxxxxxxxxxxxxxx
>
> *Subject:* Re: [Openstack] API version in Grizzly
>
>
>
> On Wed, May 8, 2013 at 4:54 PM, Gabriel Hurley <*Gabriel.Hurley@xxxxxxxxxx
> * <Gabriel.Hurley@xxxxxxxxxx>> 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.com@xxxxxxxxxxxxxxxxxxx* <nebula.com@xxxxxxxxxxxxxxxxxxx>] *On
> Behalf Of *Anne Gentle
> *Sent:* Wednesday, May 08, 2013 2:44 PM
> *To:* Devendra Gupta
> *Cc:* *openstack@xxxxxxxxxxxxxxxxxxx* <openstack@xxxxxxxxxxxxxxxxxxx>
> *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 <*dev29aug@xxxxxxxxx*<dev29aug@xxxxxxxxx>>
> 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@xxxxxxxxxxxxxxxxxxx*<openstack@xxxxxxxxxxxxxxxxxxx>
> Unsubscribe : *https://launchpad.net/~openstack*<https://launchpad.net/~openstack>
> More help   : *https://help.launchpad.net/ListHelp*<https://help.launchpad.net/ListHelp>
>
>
>
>