[openstack-dev] Mixed service version CI testing
blair.bethwaite at gmail.com
Thu Dec 28 03:41:00 UTC 2017
It may also be worth testing a step where Nova & Neutron remain at N-1.
On 20 December 2017 at 04:58, Matt Riedemann <mriedemos at gmail.com> wrote:
> During discussion in the TC channel today , 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
> 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
> 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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev