openstack team mailing list archive

[Dolph Mathews <dolph.mathews@xxxxxxxxx>]

On Tue, Jun 11, 2013 at 4:46 PM, Farhan Patwa <Farhan.Patwa@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>