[Openstack-operators] Mixed service version CI testing

Clint Byrum clint at fewbar.com
Thu Dec 28 17:28:43 UTC 2017


Excerpts from Matt Riedemann's message of 2017-12-19 09:58:34 -0600:
> During discussion in the TC channel today [1], we got talking about how 
> there is a perception that you must upgrade all of the services together 
> for anything to work, at least the 'core' services like 
> keystone/nova/cinder/neutron/glance - although maybe that's really just 
> nova/cinder/neutron?
> 
> Anyway, I posit that the services are not as tightly coupled as some 
> people assume they are, at least not since kilo era when microversions 
> started happening in nova.
> 
> However, with the way we do CI testing, and release everything together, 
> the perception is there that all things must go together to work.
> 
> In our current upgrade job, we upgrade everything to N except the 
> nova-compute service, that remains at N-1 to test rolling upgrades of 
> your computes and to make sure guests are unaffected by the upgrade of 
> the control plane.
> 
> I asked if it would be valuable to our users (mostly ops for this 
> right?) if we had an upgrade job where everything *except* nova were 
> upgraded. If that's how the majority of people are doing upgrades anyway 
> it seems we should make sure that works.
> 
> I figure leaving nova at N-1 makes more sense because nova depends on 
> the other services (keystone/glance/cinder/neutron) and is likely the 
> harder / slower upgrade if you're going to do rolling upgrades of your 
> compute nodes.
> 
> This type of job would not run on nova changes on the master branch, 
> since those changes would not be exercised in this type of environment. 
> So we'd run this on master branch changes to 
> keystone/cinder/glance/neutron/trove/designate/etc.
> 
> Does that make sense? Would this be valuable at all? Or should the 
> opposite be tested where we upgrade nova to N and leave all of the 
> dependent services at N-1?
> 

It makes sense completely. What would really be awesome would be to test
the matrix of single upgrades:

upgrade only keystone
upgrade only glance
upgrade only neutron
upgrade only cinder
upgrade only nova

That would have a good chance at catching any co-dependencies that crop
up.



More information about the OpenStack-operators mailing list