<div dir="auto">it makes sense and it is very valuable !<div dir="auto">thanks</div><div dir="auto"><br></div><div dir="auto">Saverio</div></div><div class="gmail_extra"><br><div class="gmail_quote">Il 19 dic 2017 4:59 PM, "Matt Riedemann" <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> ha scritto:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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/g<wbr>lance - although maybe that's really just nova/cinder/neutron?<br>
<br>
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.<br>
<br>
However, with the way we do CI testing, and release everything together, the perception is there that all things must go together to work.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I figure leaving nova at N-1 makes more sense because nova depends on the other services (keystone/glance/cinder/neutro<wbr>n) and is likely the harder / slower upgrade if you're going to do rolling upgrades of your compute nodes.<br>
<br>
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<wbr>/trove/designate/etc.<br>
<br>
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?<br>
<br>
Really looking for operator community feedback here.<br>
<br>
[1] <a href="http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-19.log.html#t2017-12-19T15:14:15" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org<wbr>/irclogs/%23openstack-tc/%23op<wbr>enstack-tc.2017-12-19.log.html<wbr>#t2017-12-19T15:14:15</a><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><br>
</blockquote></div></div>