<div dir="ltr"><div>Hi, <br><br></div>I have one additional question. What is your experience with updating OpenStack in place on compute nodes with out rebooting them. Can we update e.g. mitaka to newton and leave machines running on compute node running ? (if libvirt/kvm/os update is necessary we can do it after.)<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 3, 2017 at 8:22 AM, Jean-Philippe Evrard <span dir="ltr"><<a href="mailto:jean-philippe@evrard.me" target="_blank">jean-philippe@evrard.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2 November 2017 at 18:17, Chris Friesen <<a href="mailto:chris.friesen@windriver.com">chris.friesen@windriver.com</a>> wrote:<br>
> On 10/31/2017 01:13 AM, haad wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> We have an OSA installation with 10-12 compute nodes running Mitaka on<br>
>> Ubuntu<br>
>> 16.04. As initially we have not prepared any long term update strategy we<br>
>> would<br>
>> like to create one now. Plan would be to upgrade it to new OSA<br>
>> release(Ocata/Pike/Queens) in near future.<br>
>><br>
>> Our original plan was to update management/networking/backend at once by<br>
>> using<br>
>> rolling updates to newer release and then upgrade compute nodes one by one<br>
>> to<br>
>> new release.. I think that [2] provides a general upgrade manual. Is there<br>
>> any<br>
>> document describing how are different OSA releases compatible ? Is there<br>
>> any<br>
>> policy in place about backward compatibility ?<br>
><br>
><br>
> As a general rule, OpenStack only supports an online upgrade of one version<br>
> at a time.  That is, controller nodes running version N can talk to compute<br>
> nodes running version N-1.<br>
><br>
> If you can tolerate downtime of the API layer, there has been some<br>
> discussion around "skip-level" upgrades.<br>
><br>
> Chris<br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
<br>
</div></div>Hello,<br>
<br>
Having worked on "skip level" upgrades, I can tell you that it's<br>
simpler to do the upgrades in a row, because it's a more tested path.<br>
<span class="im HOEnZb"><br>
Best regards,<br>
Jean-Philippe Evrard (evrardjp)<br>
<br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-operators</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><br><br>Regards.<br><br>Adam</div>
</div>