Re: [Openstack] OpenStack API versions and release content
Hi Dolph, Thanks a lot for taking time to answer my questions. Your explanation makes things a lot clearer I do have some followup questions though. 1.) Does the 'keystone' cli support the identity v3 api features? (I am trying to use domain and groups but don't see any mention in the help section of keystone cli) 2.) If it is not yet supported by any client then when do we expect to have that available? Thanks, -Farhan. From: Dolph Mathews dolph.math...@gmail.commailto:dolph.math...@gmail.com Date: Thursday, June 13, 2013 2:11 PM To: Farhan Patwa farhan.pa...@utsa.edumailto:farhan.pa...@utsa.edu Cc: OpenStack Maillist openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack API versions and release content On Tue, Jun 11, 2013 at 4:46 PM, Farhan Patwa farhan.pa...@utsa.edumailto:farhan.pa...@utsa.edu wrote: Hi all, I am just trying to understand the motivation behind creations API versions and how that ties in to a release content. As per listed documentation (http://docs.openstack.org/api/openstack-compute/2/content/Versions-d1e1193.html) New Features and functionality that break API-compatibility necessitate a new version. When new API version are released older versions are marked as deprecated. My questions are: 1.) Is the assumption here that operators may update the release but opt to stay with an older API version to get bug fixes etc.? See #2 below. 2.) Do new versions have to be deployed with a new release? Keystone has V3 version, but I don't see it being available for use in devstack or Grizzly release (based on my assumption that the command 'keystone discover' will display supported API versions) Not necessarily. Keystone grizzly/2013.1 ships with a revised paste configuration which deploys the new Identity API v3 via pipeline:api_v3 [1]. You don't need to deploy this new pipeline at all, and a folsom paste configuration will deploy an Identity API v2 implementation just as it did in folsom. The output of keystone discover operates based on how the service catalog is populated, which doesn't necessarily reflect the configured pipeline or what's provided by the implementation. [1]: https://github.com/openstack/keystone/blob/64738924b87e6fb31d999e25da23f889a2658940/etc/keystone-paste.ini#L78 3.) Do versions have their own release schedule (so Keystone V3 is part of Grizzly code but the implementation is not yet complete or supported??) There's no such thing as Keystone v3, although that's a common misnomer. The Identity API (v2.0 - v3.0 - v3.1) is versioned independently from it's implementation, Keystone (... essex/2012.1 - folsom/2012.2 - grizzly/2013.1 - etc). Several releases of keystone could be made without incrementing the API version. A release of keystone may contain an experimental/unstable/partial and unrecommended/undocumented implementation of a newer API. A release of keystone may even skip an API version if there was reason to do so. So, for example: - diablo supports Identity API v2.0 and was extensible to support a non-OpenStack Identity API (v1.1) - essex supports Identity API v2.0 - folsom supports Identity API v2.0 - grizzly supports Identity API v2.0 and Identity API v3.0 - havana will support Identity API v2.0 and Identity API v3.1 - icehouse will support Identity API v2.0 and at least Identity API v3.1 (if not v3.2) - J*release is not guaranteed to support Identity API v2.0 and will support at least Identity API v3.1 (if not v3.3) (where minor version bumps, e.g. v3.0 - v3.1 are backwards compatible) In reality, if we ship a recommended API implementation, that API version is effectively feature frozen. So, while we could have continued to develop Identity API v3.0 past 2013.1, we documented it in the default configuration (keystone.conf.sample, devstack, etc) and shipped it with grizzly and are now working towards introducing backwards-compatible features under a minor version bump to the API that will ship with havana. I would really appreciate if someone can shed light on this. Thanks for your time, -Farhan Patwa. ___ 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] OpenStack API versions and release content
On Jun 13, 2013, at 3:11 PM, Dolph Mathews wrote: So, for example: - diablo supports Identity API v2.0 and was extensible to support a non-OpenStack Identity API (v1.1) - essex supports Identity API v2.0 - folsom supports Identity API v2.0 - grizzly supports Identity API v2.0 and Identity API v3.0 - havana will support Identity API v2.0 and Identity API v3.1 - icehouse will support Identity API v2.0 and at least Identity API v3.1 (if not v3.2) - J*release is not guaranteed to support Identity API v2.0 and will support at least Identity API v3.1 (if not v3.3) Does anyone think a matrix of OpenStack version to supported API version of each project would be useful to community developers? Should we include it in the documentation? The first column would be the OpenStack release, subsequent columns would be the projects, and the cells would be versions. For example (I hope my formatting works), Release| Keystone | Nova | etc Diablo | 2.0 | x.x | x.x Essex | 2.0 | x.x | x.x Folsom | 2.0 | x.x | x.x Grizzly| 2.0, 3.0 | x.x | x.x Havana | 2.0, 3.1 | x.x | x.x Icehouse | 2.0, 3.1 | x.x | x.x J | 3.1 | x.x | x.x Everett ___ 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] OpenStack API versions and release content
On Fri, Jun 14, 2013 at 2:10 PM, Everett Toews everett.to...@rackspace.comwrote: On Jun 13, 2013, at 3:11 PM, Dolph Mathews wrote: So, for example: - diablo supports Identity API v2.0 and was extensible to support a non-OpenStack Identity API (v1.1) - essex supports Identity API v2.0 - folsom supports Identity API v2.0 - grizzly supports Identity API v2.0 and Identity API v3.0 - havana will support Identity API v2.0 and Identity API v3.1 - icehouse will support Identity API v2.0 and at least Identity API v3.1 (if not v3.2) - J*release is not guaranteed to support Identity API v2.0 and will support at least Identity API v3.1 (if not v3.3) Does anyone think a matrix of OpenStack version to supported API version of each project would be useful to community developers? Should we include it in the documentation? Seems like a good idea to me. Dolph's email was the first clear statement I'd seen from any PTL on the subject, so I'll be watching this thread and I'll log a doc bug if there's consensus and support to publish such a table. Anne The first column would be the OpenStack release, subsequent columns would be the projects, and the cells would be versions. For example (I hope my formatting works), Release| Keystone | Nova | etc Diablo | 2.0 | x.x | x.x Essex | 2.0 | x.x | x.x Folsom | 2.0 | x.x | x.x Grizzly| 2.0, 3.0 | x.x | x.x Havana | 2.0, 3.1 | x.x | x.x Icehouse | 2.0, 3.1 | x.x | x.x J | 3.1 | x.x | x.x Everett ___ 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] OpenStack API versions and release content
On Tue, Jun 11, 2013 at 4:46 PM, Farhan Patwa farhan.pa...@utsa.edu wrote: Hi all, I am just trying to understand the motivation behind creations API versions and how that ties in to a release content. As per listed documentation ( http://docs.openstack.org/api/openstack-compute/2/content/Versions-d1e1193.html ) New Features and functionality that break API-compatibility necessitate a new version. When new API version are released older versions are marked as deprecated. My questions are: 1.) Is the assumption here that operators may update the release but opt to stay with an older API version to get bug fixes etc.? See #2 below. 2.) Do new versions have to be deployed with a new release? Keystone has V3 version, but I don't see it being available for use in devstack or Grizzly release (based on my assumption that the command 'keystone discover' will display supported API versions) Not necessarily. Keystone grizzly/2013.1 ships with a revised paste configuration which deploys the new Identity API v3 via pipeline:api_v3 [1]. You don't need to deploy this new pipeline at all, and a folsom paste configuration will deploy an Identity API v2 implementation just as it did in folsom. The output of keystone discover operates based on how the service catalog is populated, which doesn't necessarily reflect the configured pipeline or what's provided by the implementation. [1]: https://github.com/openstack/keystone/blob/64738924b87e6fb31d999e25da23f889a2658940/etc/keystone-paste.ini#L78 3.) Do versions have their own release schedule (so Keystone V3 is part of Grizzly code but the implementation is not yet complete or supported??) There's no such thing as Keystone v3, although that's a common misnomer. The Identity API (v2.0 - v3.0 - v3.1) is versioned independently from it's implementation, Keystone (... essex/2012.1 - folsom/2012.2 - grizzly/2013.1 - etc). Several releases of keystone could be made without incrementing the API version. A release of keystone may contain an experimental/unstable/partial and unrecommended/undocumented implementation of a newer API. A release of keystone may even skip an API version if there was reason to do so. So, for example: - diablo supports Identity API v2.0 and was extensible to support a non-OpenStack Identity API (v1.1) - essex supports Identity API v2.0 - folsom supports Identity API v2.0 - grizzly supports Identity API v2.0 and Identity API v3.0 - havana will support Identity API v2.0 and Identity API v3.1 - icehouse will support Identity API v2.0 and at least Identity API v3.1 (if not v3.2) - J*release is not guaranteed to support Identity API v2.0 and will support at least Identity API v3.1 (if not v3.3) (where minor version bumps, e.g. v3.0 - v3.1 are backwards compatible) In reality, if we ship a recommended API implementation, that API version is effectively feature frozen. So, while we could have continued to develop Identity API v3.0 past 2013.1, we documented it in the default configuration (keystone.conf.sample, devstack, etc) and shipped it with grizzly and are now working towards introducing backwards-compatible features under a minor version bump to the API that will ship with havana. I would really appreciate if someone can shed light on this. Thanks for your time, -Farhan Patwa. ___ 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
[Openstack] OpenStack API versions and release content
Hi all, I am just trying to understand the motivation behind creations API versions and how that ties in to a release content. As per listed documentation (http://docs.openstack.org/api/openstack-compute/2/content/Versions-d1e1193.html) New Features and functionality that break API-compatibility necessitate a new version. When new API version are released older versions are marked as deprecated. My questions are: 1.) Is the assumption here that operators may update the release but opt to stay with an older API version to get bug fixes etc.? 2.) Do new versions have to be deployed with a new release? Keystone has V3 version, but I don't see it being available for use in devstack or Grizzly release (based on my assumption that the command 'keystone discover' will display supported API versions) 3.) Do versions have their own release schedule (so Keystone V3 is part of Grizzly code but the implementation is not yet complete or supported??) I would really appreciate if someone can shed light on this. Thanks for your time, -Farhan Patwa. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
