Another tricky situation..
Given that changes to Docker were the cause of the first two backports I'd
consider those to not be exceptions, but necessary adaptations that Kolla has
to deal with. Unfortunately, this case seems more like an exception. But, I'm
not opposed to a necessary exception since we planned to deliver on it, but ran
out of time. +1 to the backport. We definitely need it.
Thanks,
Ryan
----- Original Message -----
From: "Steven Dake (stdake)" <std...@cisco.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Sent: Tuesday, March 8, 2016 1:15:10 PM
Subject: Re: [openstack-dev] [kolla][vote] exception for backporting upgrades
to liberty/stable
Exceptions can always be rationalized which is one reason exceptions are evil
among many. The facts however speak for themselves. If we don't have a way to
introduce new content in liberty when CVEs are fixed, stable/liberty is just as
flawed as the data loss problem which was the original trigger for the
backporting of the playbooks in the first place to introduce named volumes.
As a result, I am +1 to 1.1.0 backport.
I am –1 to a 1.2.0 because back to back releases are a pain in the ass to
manage and offer little value. 1.1.1 without upgrades would be flawed just as
1.1.0 is today.
Regards
-steve
From: Steven Dake < std...@cisco.com >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org >
Date: Monday, March 7, 2016 at 8:03 AM
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org >
Subject: [openstack-dev] [kolla][vote] exception for backporting upgrades to
liberty/stable
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.
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-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
