Open Stack

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