So, it looks like we have an agreement on all question. There is only one technical question - keeping release images means that we need to keep the whole matrix of images: plugin X version X OSy [X root-passwdord]. I'll take a look on total size of them and ability to publish them on OS infra.
On Thu, May 29, 2014 at 5:54 PM, Trevor McKay <tmc...@redhat.com> wrote: > Catching up... > > On Thu, 2014-05-29 at 15:59 +0400, Alexander Ignatov wrote: >> On 28 May 2014, at 17:14, Sergey Lukjanov <slukja...@mirantis.com> wrote: >> > 1. How should we handle addition of new functionality to the API, >> > should we bump minor version and just add new endpoints? >> >> Agree with most of folks. No new versions on adding new endpoints. >> Semantic changes require new major version of rest api. > > +1 this and previous comments. I don't think we'll generate too many > semantic changes (but I could be wrong :) ) > > I agree with Mike that we should have simple version numbers, v1, v2, v3 > >> > 2. For which period of time should we keep deprecated API and client for >> > it? >> >> One release cycle for deprecation period. > > +1. If we give folks N cycles, they will always wait until the Nth > cycle to move away. Might as well be 1. > >> >> > 3. How to publish all images and/or keep stability of building images >> > for plugins? >> > >> >> We should keep all images for all plugins (non-deprecated as Matt mentioned) >> for each release. In addition we could keep at least one image which could >> be >> downloaded and used with master branch of Sahara. Plugin vendors could keep >> its own set of images and we can reflect it in the docs. > > I agree with keeping all images grouped with a release for all supported > plugins in that release. > > Are we suggesting here that there are 2 places to find images, one in > the Sahara releases and a second in a vendor repo listed in the docs? > >> Regards, >> Alexander Ignatov >> >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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