<div dir="ltr"><div>Thanks for starting the thread, Ruby.</div><div><br></div><div><br></div>We need to first establish a grenade job to test "cold upgrades" and assert the supports-upgrade tag. I believe Ironic meets all the criteria for that tag except:<div>- having a job that tests it (so, you know, it might be broken and I might be wrong)</div><div>- having operator documentation describing the process (it should be here: <a href="http://docs.openstack.org/developer/ironic/deploy/upgrade-guide.html">http://docs.openstack.org/developer/ironic/deploy/upgrade-guide.html</a> ) but all we have are release-specific upgrade notes.<br><div><br></div></div><div>I think all of the scenario you outline are valid upgrade paths for an operator, and we should try to allow all of them to work. However, some of them can be covered by one test case, and you also missed some things I think need to be covered. Also, I'm interpreting the word "master" in your scenarios to indicate the proposed change to our master branch, since we do pre-merge testing....</div><div><br></div><div>So, here are the test cases I think we need to cover:</div><div><div><br class="">=== run on proposed changes to master ===</div></div><div><br></div><div>F. current master to new SHA</div><div><br></div><div>We need to ensure that we can upgrade master to the code being proposed. You listed this last, but I think it's actually the most important one.</div><div><br></div><div>D. last named release to new SHA</div><div>E. last numbered release to new SHA</div><div><br></div><div>Because we cut new releases from master, this is the basis of testing the upgrade between sequential (named or numbered) releases before we cut a new (named or numbered) release, and is our most important test to ensure that we don't break most operators. Based on the user survey, most operators are using named releases, so if we are resource constrained, I would prefer to cover (D) before (E)<br></div><div><br></div><div>=== run on proposed changes to a stable branch ===</div><div><br></div><div>A. stable/N-1 -> new SHA -> [ stable/N+1 or current master]<br></div><div><br></div><div>We don't need to test upgrades between two named releases (eg. Liberty -> Mitaka) every time we land a new patch on the master branch, but we do need to test any time we land a change on a stable branch. Changes to the most recent stable branch should be upgrade-tested to current master, whereas changes to any stable branch prior to that should get tested to the subsequent sequential release.</div><div><br></div><div>Eg, a backport to stable/liberty should trigger an upgrade test for both (stable/kilo -> newpatch) and (newpatch  -> stable/mitaka), whereas a backport to stable/mitaka should trigger a test for (stable/liberty -> newpatch) and (newpatch -> master)</div><div><br></div><div><div><br class="">Once we've done that, then yes, I agree we should also work towards asserting supports-rolling-upgrade. That will require a partial upgrade job, eg. where we run >1 instance of the API and Conductor services and upgrade some of them.</div></div><div><br></div><div>Regards,</div><div>Devananda</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 19, 2016 at 12:52 PM, Ruby Loo <span dir="ltr"><<a href="mailto:opensrloo@gmail.com" target="_blank">opensrloo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div>Hi,<br><br></div>Currently, ironic doesn't support ("live", "online", "rolling", or minimal-downtime) upgrades between named versions of ironic. (Where "named version" is the final release or stable release that is associated with a development cycle). So for example, Liberty -> Mitaka release.<br><br></div>We've been working towards that, and have a spec [1] and a design session [2] at the Austin Summit. Upon reading the spec, I started to wonder -- what do we mean/want, when we talk about supporting upgrades. Do we want to support:<br></div>A. sequential named releases, eg. Mitaka -> Newton<br></div>B. sequential major releases, eg 4.x -> 5.0; 5.0 -> 6.1<br></div><div>C. sequential minor releases, eg 5.1 -> 5.2<br></div><div>D. last named release to master<br></div><div>E. last release (major or minor) to master<br></div><div>F. some-SHA-more-recent-than-last-named to master. This could be some numbered (major or minor) release.<br></div><div><br></div>Keep in mind that ironic may release any number of numbered releases between two named releases, so eg. 4.3.0, 5.0.0, 5.1.0 == Mitaka, 5.2.0, 6.0.0, 6.1.0, 7.0.0, 7.1.0, 7.2.0 == Newton.<br></div><div><br></div>Note that there are two governance tags: supports-upgrade[3] and supports-rolling-upgrade[4], and I believe our goal is for supports-rolling-upgrade.<br></div><br></div><div>I think and hope that we can all agree that A. is a must :)<br><br></div><div>What constitutes a major release versus a minor release may have implications in this, but that should be in a separate discussion.<br></div><div><br>What do people think?<br><br></div>--ruby<br><div><div><div><div><div><div><div><br>[1] <span><a href="https://review.openstack.org/299245" rel="noreferrer" target="_blank">https://review.openstack.org/299245</a></span><br>[2] <a href="https://www.openstack.org/summit/austin-2016/summit-schedule/events/9267" target="_blank">https://www.openstack.org/summit/austin-2016/summit-schedule/events/9267</a><br>[3] <a href="https://github.com/openstack/governance/blob/master/reference/tags/assert_supports-upgrade.rst" target="_blank">https://github.com/openstack/governance/blob/master/reference/tags/assert_supports-upgrade.rst</a><br>[4] <a href="https://github.com/openstack/governance/blob/master/reference/tags/assert_supports-rolling-upgrade.rst" target="_blank">https://github.com/openstack/governance/blob/master/reference/tags/assert_supports-rolling-upgrade.rst</a><br></div></div></div></div></div></div></div></div>
<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></blockquote></div><br></div>