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.
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.html
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.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://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
