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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev