it makes sense and it is very valuable ! thanks Saverio
Il 19 dic 2017 4:59 PM, "Matt Riedemann" <mriede...@gmail.com> ha scritto: > 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? > > Really looking for operator community feedback here. > > [1] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23op > enstack-tc.2017-12-19.log.html#t2017-12-19T15:14:15 > > -- > > Thanks, > > Matt > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > 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
