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.com<mailto:dolph.math...@gmail.com>> Date: Thursday, June 13, 2013 2:11 PM To: Farhan Patwa <farhan.pa...@utsa.edu<mailto:farhan.pa...@utsa.edu>> Cc: OpenStack Maillist <openstack@lists.launchpad.net<mailto: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.edu<mailto: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<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
