<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 20, 2016 at 5:38 AM, Mathieu Mitchell <span dir="ltr"><<a href="mailto:mmitchell@internap.com" target="_blank">mmitchell@internap.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 2016-04-19 11:29 PM, Tan, Lin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree this is reasonable to support all these cases in “cold upgrades” but in supports-rolling-upgrade (live upgrade in another word) case it is different and complicated and not necessary,<br>
<br>
During rolling upgrade, we will have old/new services co-existed, and we need to make services compatible which need some extra code work and this is the main purpose of spec [1]. And as far as I can see, we are  not allowed to skip over releases when rolling upgrading.  So my point is support name release is enough.<br>
<br>
1. Because even if we want to support major number release, admins have to upgrade from 5.0 -> 6.0 then 6.0 -> 7.0 in Ruby’s case of 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. And we might have a higher release frequency in the future. So it’s too much work for upgrade a service every six months.<br>
<br>
2. As we usually rolling upgrade the whole cloud, not for ironic only. For example, other projects will upgrade from Mitaka to Netwon, there is not much sense to upgrade Ironic from 5.0 -> 6.0 only.<br>
<br>
</blockquote>
<br></span>
As an operator, I disagree with that statement. We follow different upgrade paths for Ironic and Glance for example. My area of concern around Ironic is compatibility with Nova and Neutron. If we can prove via CI that Nova on an older version still works with Ironic on master and vice versa, we will successfully avoid having to do them in a lockstep.</blockquote><div><br></div><div>I agree that we need to test this scenario and assert via CI that it is possible to upgrade Nova and Ironic separately, and as we're adding Neutron integration, we will need to assert the same thing there. Let's call this a "cloud rolling upgrade". We'll want to run this test on changes in Nova as well.</div><div><br></div><div>We can test that with the grenade partial job. I do not think we need to test the upgrade sequence in both directions, though -- as we integrate with more services, that would explode exponentially. Instead, we should proscribe an order to the upgrades (and document it clearly) and then test that ordering. For starters, I would upgrade Ironic first (our API needs to remain backwards compatible) and then upgrade Nova. That said, I'm not sure how adding Neutron, or eventually Cinder, will affect the upgrade sequence.</div><div><br></div><div>Just to be clear, this doesn't replace the need to assert a "service rolling upgrade", eg. where different releases of the Ironic API and Conductor services are run at the same time, but we could do that in a test environment that is only running Ironic, and wouldn't need to trigger that test on changes in Nova, for example.</div><div><br></div><div>--deva</div></div></div></div>