Open Stack

it makes sense and it is very valuable !
thanks

Saverio

Il 19 dic 2017 4:59 PM, "Matt Riedemann" <mriedemos at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20171219/558354fd/attachment.html>