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. _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
