Open Stack

On 3/7/16, 10:16 AM, "Paul Bourke" <paul.bourke at oracle.com> wrote:

>This is a messy topic. I feel there's been some miscommunication and
>confusion on the issue which hopefully I can sum up.
>
>As far as I remember it, Sam is correct, we did always plan to do
>Liberty upgrades. However, over the course of time post Tokyo these
>plans didn't really materialise, at which point Micheal kindly stepped
>forward to kick things into action [0].
>
>Between now and then the focus shifted to "how do we get from Liberty to
>Mitaka", and the original discussion of moving between minor Liberty
>releases fell by the wayside. I think this is where the confusion has
>arisen.

This is accurate.  It wasn¹t a matter of not materializing, however, we
were capacity constrained.  We will have upgrades working for Mitaka but
it required a lot of everyone's time.

Regards
-stev

>
>As I mentioned before I have been opposed to backporting features to
>stable/liberty, as this is against the philosophy of a stable branch
>etc. etc. However, as has been mentioned many times before, this is a
>new project, hindsight is a great thing. Ideally users running Liberty
>who encounter a CVE could be told to go to Mitaka, but in reality this
>is an unreasonable expectation and operators who have gone on our
>previous release notes that Liberty is ready to rock will feel screwed
>over.
>
>So based on the above I am +1 to get upgrades into Liberty, I hope this
>makes sense.
>
>Regards,
>-Paul
>
>[0] 
>http://lists.openstack.org/pipermail/openstack-dev/2015-December/081467.ht
>ml
>
>On 07/03/16 16:00, Sam Yaple wrote:
>> On Mon, Mar 7, 2016 at 3:03 PM, Steven Dake (stdake) <stdake at cisco.com
>> <mailto: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.h
>>tml#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://OpenStack-dev-request@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
>>
>
>__________________________________________________________________________
>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