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