Open Stack

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.

> 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.

> 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.

-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
Mirantis Inc.