Open Stack

On Tue, Mar 8, 2016 at 2:41 AM, Steven Dake (stdake) <stdake at cisco.com>
wrote:

>
>
> 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.
>

The initial work on upgrade took some time, but that doesn't mean it's not
an easy backport to Liberty. As far as I can tell it's perfectly isolated
code and can be backported without too much trouble.

I'd like to stick to what we agreed in Tokyo, I'm +1 on backporting upgrade
playbooks to 1.1.0.

Martin


> 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
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160308/5f866289/attachment.html>