Open Stack

On Wed, Apr 20, 2016 at 5:38 AM, Mathieu Mitchell <mmitchell at internap.com>
wrote:

>
>
> On 2016-04-19 11:29 PM, Tan, Lin wrote:
>
>> 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,
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>>
> 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.


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.

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.

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.

--deva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160420/8d8ab7d7/attachment.html>