[openstack-dev] [sahara] summit wrap-up: backward compat

Matthew Farrellee matt at redhat.com
Wed May 28 18:46:40 UTC 2014


On 05/28/2014 09:14 AM, Sergey Lukjanov wrote:
> Hey folks,
>
> it's a small wrap-up for the two topics "Sahara backward compat" and "
> "Hadoop cluster backward compatibility", both were discussed on design
> summit, etherpad [0] contains info about them. There are some open
> questions listed in the end of email, please, don't skip them :)
>
>> Sahara backward compat
>
> Keeping released APIs stable since the Icehouse release. So, for now
> we have one stable API v1.1 (and v1.0 as a subset for it). Any changes
> to existing semantics requires new API version, additions handling is
> a question. As part of API stability decision python client should
> work with all previous Sahara versions. API of python-saharaclient
> should be stable itself, because we aren't limiting the client version
> for OpenStack release, so, the client v123 shouldn't change own API
> exposed to user that is working with stable release REST API versions.

for juno we should just have a v1 api (there can still be a v1.1 
endpoint, but it should be deprecated), and maybe a v2 api

+1 any semantic changes require new major version number

+1 api should only have a major number (no 1.1 or 2.1)


>> Hadoop cluster backward compat
>
> It was decided to at least keep released versions of cluster (Hadoop)
> plugins for the next release, so, It means if we have vanilla-2.0.1
> released as part of Icehouse, than we could remove it's support only
> after releasing it as part of Juno with note that it's deprecated and
> will not be available in the next release. Additionally, we've decided
> to add some docs with upgrade recommendations.

we should only be producing images for the currently supported plugin 
versions. images for deprecated versions can be found with the releases 
where the version wasn't deprecated.


best,


matt

>> Open questions
>
> 1. How should we handle addition of new functionality to the API,
> should we bump minor version and just add new endpoints?
> 2. For which period of time should we keep deprecated API and client for it?
> 3. How to publish all images and/or keep stability of building images
> for plugins?
>
> [0] https://etherpad.openstack.org/p/juno-summit-sahara-relmngmt-backward
>
> Thanks.
>




More information about the OpenStack-dev mailing list