Open Stack

Upgrades are required, true, but not necessarily automatic ones.
People still can rebuild and redeploy containers using normal deploy.
It will be downtime causing and less optimal, but possible. Also with
backport of named volumes it won't be data-destroying. It will cause
total downtime of APIs, but well, it's first version.

So I'm -1 to porting it to 1.1.0.

But I would suggest another option, namely 1.2.0 with automatic
upgrades we have now. It will allow upgrade 1.1.0->1.2.0 and it will
not add more work to 1.1.0 which we need asap (we need it well tested
by Austin summt AT MOST). Adding upgrades might make it tight,
especially that infra upgrades aren't finished yet in master.

Cheers,
Michal

On 7 March 2016 at 10:00, Sam Yaple <samuel at yaple.net> wrote:
> On Mon, Mar 7, 2016 at 3:03 PM, Steven Dake (stdake) <stdake at cisco.com>
> wrote:
>>
>> Hi folks,
>>
>> It was never really discussed if we would back-port upgrades to liberty.
>> This came up during  an irc conversation Friday [1], and a vote was
>> requested.  Tthe facts of the discussion distilled are:
>>
>> We never agreed as a group to do back-port of upgrade during our back-port
>> discussion
>> An operator that can't upgrade her Z version of Kolla (1.1.1 from 1.1.0)
>> is stuck without CVE or OSSA corrections.
>> Because of a lack of security upgrades, the individual responsible for
>> executing the back-port would abandon the work (but not tuse the abaondon
>> feature for of gerrit for changes already in the queue)
>>
>> Since we never agreed, in that IRC discussion a vote was requested, and I
>> am administering the vote.  The vote request was specifically should we have
>> a back-port of upgrade in 1.1.0.  Both parties agreed they would live with
>> the results.
>>
>> I would like to point out that not porting upgrades means that the liberty
>> branch would essentially become abandoned unless some other brave soul takes
>> up a backport.  I would also like to point out that that is yet another
>> exception much like thin-containers back-port which was accepted.  See how
>> exceptions become the way to the dark side.  We really need to stay
>> exception free going forward (in Mitaka and later) as much as possible to
>> prevent expectations that we will make exceptions when none should be made.
>>
>
> This is not an exception. This was always a requirement. If you disagree
> with that then we have never actually had a stable branch. The fact is we
> _always_ needed z version upgrades for Kolla. It was _always_ the plan to
> have them. Feel free to reference the IRC logs and our prior mid-cycle and
> our Tokyo upgrade sessions. What changed was time and peoples memories and
> that's why this is even a conversation.
>
>>
>> Please vote +1 (backport) or –1 (don’t backport).  An abstain in this case
>> is the same as voting –1, so please vote either way.  I will leave the
>> voting open for 1 week until April 14th.  If there I a majority in favor, I
>> will close voting early.  We currently require 6 votes for majority as our
>> core team consists of 11 people.
>>
>> Regards,
>> -steve
>>
>>
>> [1]
>> http://eavesdrop.openstack.org/irclogs/%23kolla/%23kolla.2016-03-04.log.html#t2016-03-04T18:23:26
>>
>> Warning [1] was a pretty heated argument and there may have been some
>> swearing :)
>>
>> voting.
>>
>> "Should we back-port upgrades
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> Obviously I am +1 on committing to a stable _stable_ branch. And that has
> always required Z upgrades. Luckily the work we did in master is also usable
> for z upgrades. Without the ability to perform an update after a
> vulnerability, we have to stable branch.
>
> I would remind every one we _did_ have this conversation in Tokyo when we
> discussed pinning to stable versions of other projects rather than using
> head of thier stable branch. We currently do that and there is a review for
> a tool to make that even easier to maintain [1]. There was even talk of a
> bot to purpose these bumps in versions. That means z upgrades were expected
> for Liberty. Anyone thinking otherwise has a short memory.
>
> [1] https://review.openstack.org/#/c/248481/
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>