On Tue, Mar 8, 2016 at 2:41 AM, Steven Dake (stdake) <std...@cisco.com> wrote:
> > > On 3/7/16, 10:16 AM, "Paul Bourke" <paul.bou...@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) <std...@cisco.com > >> <mailto:std...@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-requ...@lists.openstack.org?subject:unsubscribe > >> > >><http://openstack-dev-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
