Re: [Openstack] API version in Grizzly
Thanks! Gabriel. I understood. Devendra On 10-May-13 11:46 PM, Gabriel Hurley wrote: When you say Identity v3.0 development is going on side-by-side so I think if I have Grizzly setup with Identity v2.0 then it'll be upgraded to Identity v3.0 with Grizzly when new version is available in updates. Though I might have option to upgrade it or not? OR Identity v3.0 will be released with Havana ? I believe you're still a little confused by what it means to upgrade to an API. The API version(s) are an inherent part of a particular release. Grizzly features both v2.0 and v3 Keystone APIs. They're both there. It's up to you when you want to upgrade to it by changing your endpoints, scripts, clients, etc. to take advantage of the new API. There will be further refinements in Havana, but v3 is here now. Another thing looks confusing to me in API Specification page http://docs.openstack.org/api/api-specs.html, we have version number mentioned with v1.0/v2.0 for some components (e.g. Object, Identity, Networking) but v1/v2 for few others (e.g. Image, Compute). Is there any special reason to not put .0 in version for some components ? The inconsistency is legitimate, not merely an oversight. Keystone dropped the .0 for the major versions in its URL structure. As such you would use http://host:5000/v2.0/ for v2.0 and http://host:5000/v3/ for the v3 API. Other services have chosen to include or exclude the .0 as they see fit. Unfortunately right now you just have to look up what the proper numbering format is for a particular API. All the best, - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] API version in Grizzly
I have few more questions related to APIs. When you say Identity v3.0 development is going on side-by-side so I think if I have Grizzly setup with Identity v2.0 then it'll be upgraded to Identity v3.0 with Grizzly when new version is available in updates. Though I might have option to upgrade it or not? OR Identity v3.0 will be released with Havana ? Another thing looks confusing to me in API Specification page http://docs.openstack.org/api/api-specs.html, we have version number mentioned with v1.0/v2.0 for some components (e.g. Object, Identity, Networking) but v1/v2 for few others (e.g. Image, Compute). Is there any special reason to not put .0 in version for some components ? Thanks, Devendra On Friday 10 May 2013 07:30 PM, Devendra Gupta wrote: Thanks! Joi. I understood. Devendra On Thursday 09 May 2013 09:03 PM, heckj wrote: That's not entirely the case - the API structure has changed rather significantly (mostly made more consistent and unified), so API calls to V2 may or may not match entirely with API calls to V3. We did go to the trouble of writing a very thorough spec, and then checking and updating it as we did the V3 API implementation. You can find that spec at https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md The WADL's that generate the V2 API didn't expose or explicitly set many of the administrative functions in V2, although the data structures returned a very similiar - there's also some additional concepts that are only exposed in V3 (domains, groups) - which may or may not be relevant to what you're trying to do. tl;dr - don't assume the API translates perfectly forward - joe On May 9, 2013, at 7:24 AM, Devendra Gupta dev29...@gmail.com wrote: Thanks, Anne and Gabriel. So I believe, if we develop something based on Identity v2.0 API then it will also support Identity v3.0, please correct me if I am wrong. Thanks, Devendra Gupta On 09-May-13 5:27 AM, Gabriel Hurley wrote: In Grizzly I can send Keystone requests to either _http://keyston__e_host:5000/v2.0/_ http://keystone_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. As for 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. J All the best, * Gabriel *From:* 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 *Subject:* Re: [Openstack] API version in Grizzly On Wed, May 8, 2013 at 4:54 PM, Gabriel Hurley _Gabriel.Hurley@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.com@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
Re: [Openstack] API version in Grizzly
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.commailto: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.orghttp://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.commailto: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.netmailto: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.commailto: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.orghttp://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.hurleymailto:openstack-bounces%2Bgabriel.hurley=nebula@lists.launchpad.netmailto:nebula@lists.launchpad.net] On Behalf Of Anne Gentle Sent: Wednesday, May 08, 2013 2:44 PM To: Devendra Gupta Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] API version in Grizzly Hi Devendra, Generally the guidance for the api.openstack.orghttp://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.commailto: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
Re: [Openstack] API version in Grizzly
When you say Identity v3.0 development is going on side-by-side so I think if I have Grizzly setup with Identity v2.0 then it'll be upgraded to Identity v3.0 with Grizzly when new version is available in updates. Though I might have option to upgrade it or not? OR Identity v3.0 will be released with Havana ? I believe you're still a little confused by what it means to upgrade to an API. The API version(s) are an inherent part of a particular release. Grizzly features both v2.0 and v3 Keystone APIs. They're both there. It's up to you when you want to upgrade to it by changing your endpoints, scripts, clients, etc. to take advantage of the new API. There will be further refinements in Havana, but v3 is here now. Another thing looks confusing to me in API Specification page http://docs.openstack.org/api/api-specs.html, we have version number mentioned with v1.0/v2.0 for some components (e.g. Object, Identity, Networking) but v1/v2 for few others (e.g. Image, Compute). Is there any special reason to not put .0 in version for some components ? The inconsistency is legitimate, not merely an oversight. Keystone dropped the .0 for the major versions in its URL structure. As such you would use http://host:5000/v2.0/ for v2.0 and http://host:5000/v3/ for the v3 API. Other services have chosen to include or exclude the .0 as they see fit. Unfortunately right now you just have to look up what the proper numbering format is for a particular API. All the best, - Gabriel ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] API version in Grizzly
Thanks, Anne and Gabriel. So I believe, if we develop something based on Identity v2.0 API then it will also support Identity v3.0, please correct me if I am wrong. Thanks, Devendra Gupta On 09-May-13 5:27 AM, Gabriel Hurley wrote: In Grizzly I can send Keystone requests to either _http://keyston__e_host:5000/v2.0/_ http://keystone_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. As for 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. J All the best, * Gabriel *From:* 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 *Subject:* Re: [Openstack] API version in Grizzly On Wed, May 8, 2013 at 4:54 PM, Gabriel Hurley _Gabriel.Hurley@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.com@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 _dev29aug@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_
Re: [Openstack] API version in Grizzly
On Wed, May 8, 2013 at 6:57 PM, Gabriel Hurley gabriel.hur...@nebula.comwrote: 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.orgsite 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.orgsite 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
Re: [Openstack] API version in Grizzly
That's not entirely the case - the API structure has changed rather significantly (mostly made more consistent and unified), so API calls to V2 may or may not match entirely with API calls to V3. We did go to the trouble of writing a very thorough spec, and then checking and updating it as we did the V3 API implementation. You can find that spec at https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md The WADL's that generate the V2 API didn't expose or explicitly set many of the administrative functions in V2, although the data structures returned a very similiar - there's also some additional concepts that are only exposed in V3 (domains, groups) - which may or may not be relevant to what you're trying to do. tl;dr - don't assume the API translates perfectly forward - joe On May 9, 2013, at 7:24 AM, Devendra Gupta dev29...@gmail.com wrote: Thanks, Anne and Gabriel. So I believe, if we develop something based on Identity v2.0 API then it will also support Identity v3.0, please correct me if I am wrong. Thanks, Devendra Gupta On 09-May-13 5:27 AM, Gabriel Hurley wrote: In Grizzly I can send Keystone requests to either _http://keyston__e_host:5000/v2.0/_ http://keystone_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. As for 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. J All the best, * Gabriel *From:* 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 *Subject:* Re: [Openstack] API version in Grizzly On Wed, May 8, 2013 at 4:54 PM, Gabriel Hurley _Gabriel.Hurley@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.com@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 _dev29aug@gmail.com_ mailto:dev29...@gmail.com
[Openstack] API version in Grizzly
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 Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] API version in Grizzly
Hi Devendra, Generally the guidance for the 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 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 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
Re: [Openstack] API version in Grizzly
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. In the future I believe the 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. ;-) - Gabriel From: Openstack [mailto:openstack-bounces+gabriel.hurley=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 Subject: Re: [Openstack] API version in Grizzly Hi Devendra, Generally the guidance for the api.openstack.orghttp://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.commailto: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.netmailto: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
Re: [Openstack] API version in Grizzly
On Wed, May 8, 2013 at 4:54 PM, Gabriel Hurley gabriel.hur...@nebula.comwrote: 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 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= 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 *Subject:* Re: [Openstack] API version in Grizzly ** ** Hi Devendra, Generally the guidance for the 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 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 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
Re: [Openstack] API version in Grizzly
In Grizzly I can send Keystone requests to either http://keystone_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. As for 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. :) All the best, - Gabriel From: 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 Subject: Re: [Openstack] API version in Grizzly On Wed, May 8, 2013 at 4:54 PM, Gabriel Hurley gabriel.hur...@nebula.commailto: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.orghttp://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.hurleymailto:openstack-bounces%2Bgabriel.hurley=nebula@lists.launchpad.netmailto:nebula@lists.launchpad.net] On Behalf Of Anne Gentle Sent: Wednesday, May 08, 2013 2:44 PM To: Devendra Gupta Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] API version in Grizzly Hi Devendra, Generally the guidance for the api.openstack.orghttp://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.commailto: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.netmailto: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
