<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 8, 2016 at 2:41 AM, Steven Dake (stdake) <span dir="ltr"><<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
On 3/7/16, 10:16 AM, "Paul Bourke" <<a href="mailto:paul.bourke@oracle.com" target="_blank">paul.bourke@oracle.com</a>> wrote:<br>
<br>
>This is a messy topic. I feel there's been some miscommunication and<br>
>confusion on the issue which hopefully I can sum up.<br>
><br>
>As far as I remember it, Sam is correct, we did always plan to do<br>
>Liberty upgrades. However, over the course of time post Tokyo these<br>
>plans didn't really materialise, at which point Micheal kindly stepped<br>
>forward to kick things into action [0].<br>
><br>
>Between now and then the focus shifted to "how do we get from Liberty to<br>
>Mitaka", and the original discussion of moving between minor Liberty<br>
>releases fell by the wayside. I think this is where the confusion has<br>
>arisen.<br>
<br>
</span>This is accurate. It wasn¹t a matter of not materializing, however, we<br>
were capacity constrained. We will have upgrades working for Mitaka but<br>
it required a lot of everyone's time.<br></blockquote><div><br></div><div>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.<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">I'd like to stick to what we agreed in Tokyo, I'm +1 on backporting upgrade playbooks to 1.1.0.<br><br></div><div class="gmail_quote">Martin<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regards<br>
-stev<br>
<div><div><br>
><br>
>As I mentioned before I have been opposed to backporting features to<br>
>stable/liberty, as this is against the philosophy of a stable branch<br>
>etc. etc. However, as has been mentioned many times before, this is a<br>
>new project, hindsight is a great thing. Ideally users running Liberty<br>
>who encounter a CVE could be told to go to Mitaka, but in reality this<br>
>is an unreasonable expectation and operators who have gone on our<br>
>previous release notes that Liberty is ready to rock will feel screwed<br>
>over.<br>
><br>
>So based on the above I am +1 to get upgrades into Liberty, I hope this<br>
>makes sense.<br>
><br>
>Regards,<br>
>-Paul<br>
><br>
>[0]<br>
><a href="http://lists.openstack.org/pipermail/openstack-dev/2015-December/081467.ht" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-December/081467.ht</a><br>
>ml<br>
><br>
>On 07/03/16 16:00, Sam Yaple wrote:<br>
>> On Mon, Mar 7, 2016 at 3:03 PM, Steven Dake (stdake) <<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a><br>
>> <mailto:<a href="mailto:stdake@cisco.com" target="_blank">stdake@cisco.com</a>>> wrote:<br>
>><br>
>> Hi folks,<br>
>><br>
>> It was never really discussed if we would back-port upgrades to<br>
>> liberty. This came up during an irc conversation Friday [1], and a<br>
>> vote was requested. Tthe facts of the discussion distilled are:<br>
>><br>
>> * We never agreed as a group to do back-port of upgrade during our<br>
>> back-port discussion<br>
>> * An operator that can't upgrade her Z version of Kolla (1.1.1<br>
>> from 1.1.0) is stuck without CVE or OSSA corrections.<br>
>> * Because of a lack of security upgrades, the individual<br>
>> responsible for executing the back-port would abandon the work<br>
>> (but not tuse the abaondon feature for of gerrit for changes<br>
>> already in the queue)<br>
>><br>
>> Since we never agreed, in that IRC discussion a vote was requested,<br>
>> and I am administering the vote. The vote request was specifically<br>
>> should we have a back-port of upgrade in 1.1.0. Both parties agreed<br>
>> they would live with the results.<br>
>><br>
>> I would like to point out that not porting upgrades means that the<br>
>> liberty branch would essentially become abandoned unless some other<br>
>> brave soul takes up a backport. I would also like to point out that<br>
>> that is yet another exception much like thin-containers back-port<br>
>> which was accepted. See how exceptions become the way to the dark<br>
>> side. We really need to stay exception free going forward (in<br>
>> Mitaka and later) as much as possible to prevent expectations that<br>
>> we will make exceptions when none should be made.<br>
>><br>
>> This is not an exception. This was always a requirement. If you disagree<br>
>> with that then we have never actually had a stable branch. The fact is<br>
>> we _always_ needed z version upgrades for Kolla. It was _always_ the<br>
>> plan to have them. Feel free to reference the IRC logs and our prior<br>
>> mid-cycle and our Tokyo upgrade sessions. What changed was time and<br>
>> peoples memories and that's why this is even a conversation.<br>
>><br>
>> Please vote +1 (backport) or 1 (don¹t backport). An abstain in<br>
>> this case is the same as voting 1, so please vote either way. I<br>
>> will leave the voting open for 1 week until April 14th. If there I<br>
>> a majority in favor, I will close voting early. We currently<br>
>> require 6 votes for majority as our core team consists of 11 people.<br>
>><br>
>> Regards,<br>
>> -steve<br>
>><br>
>><br>
>> [1]<br>
>><br>
>><a href="http://eavesdrop.openstack.org/irclogs/%23kolla/%23kolla.2016-03-04.log.h" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/irclogs/%23kolla/%23kolla.2016-03-04.log.h</a><br>
>>tml#t2016-03-04T18:23:26<br>
>><br>
>> Warning [1] was a pretty heated argument and there may have been<br>
>> some swearing :)<br>
>><br>
>> voting.<br>
>><br>
>> "Should we back-port upgrades<br>
>><br>
>><br>
>>_________________________________________________________________________<br>
>>_<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>><br>
>><<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>> Obviously I am +1 on committing to a stable _/stable_/ branch. And that<br>
>> has always required Z upgrades. Luckily the work we did in master is<br>
>> also usable for z upgrades. Without the ability to perform an update<br>
>> after a vulnerability, we have to stable branch.<br>
>><br>
>> I would remind every one we _did_ have this conversation in Tokyo when<br>
>> we discussed pinning to stable versions of other projects rather than<br>
>> using head of thier stable branch. We currently do that and there is a<br>
>> review for a tool to make that even easier to maintain [1]. There was<br>
>> even talk of a bot to purpose these bumps in versions. That means z<br>
>> upgrades were expected for Liberty. Anyone thinking otherwise has a<br>
>> short memory.<br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/248481/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/248481/</a><br>
>><br>
>><br>
>><br>
>>_________________________________________________________________________<br>
>>_<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>