Re: [Openstack-operators] [openstack-dev] Mixed service version CI testing
+1! It may also be worth testing a step where Nova & Neutron remain at N-1. On 20 December 2017 at 04:58, Matt Riedemann wrote: > 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/%23openstack-tc.2017-12-19.log.html#t2017-12-19T15:14:15 > > -- > > Thanks, > > Matt > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Cheers, ~Blairo ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] Mixed service version CI testing
On Tue, Dec 19, 2017 at 10:58 AM, Matt Riedemann wrote: > 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. I'd def like to see something like this. Thanks, Curtis. > > [1] > http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-19.log.html#t2017-12-19T15:14:15 > > -- > > Thanks, > > Matt > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Blog: serverascode.com ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators