We usually upgrade nova last so would be helpful. Nectar has been running a mix of versions for a couple of years now and we treat each project as it’s own thing and upgrade everything separately.
You can see what versions we run currently at https://trello.com/b/9fkuT1eU/nectar-openstack-versions <https://trello.com/b/9fkuT1eU/nectar-openstack-versions> Sam > On 29 Dec 2017, at 4:28 am, Clint Byrum <cl...@fewbar.com> wrote: > > 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 > OpenStack-operators@lists.openstack.org > <mailto:OpenStack-operators@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators>
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators