Hello, I think you'll face end user downtime anyway, due to _at least_ neutron agents flapping. But yes it can be fairly limited. I can't say for restart or no restart. I think it's possible to do without restarting, but I also think you should have plan for the restarts, else how do you do your critical security updates for things like kernel?
Just my 2 cents, it's probably good to have other opinions out there. Best regards, Jean-Philippe Evrard (evrardjp) On 3 November 2017 at 13:19, haad <haa...@gmail.com> wrote: > Hi, > > 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.) > > On Fri, Nov 3, 2017 at 8:22 AM, Jean-Philippe Evrard > <jean-phili...@evrard.me> wrote: >> >> On 2 November 2017 at 18:17, Chris Friesen <chris.frie...@windriver.com> >> wrote: >> > On 10/31/2017 01:13 AM, haad wrote: >> >> >> >> Hi, >> >> >> >> We have an OSA installation with 10-12 compute nodes running Mitaka on >> >> Ubuntu >> >> 16.04. As initially we have not prepared any long term update strategy >> >> we >> >> would >> >> like to create one now. Plan would be to upgrade it to new OSA >> >> release(Ocata/Pike/Queens) in near future. >> >> >> >> Our original plan was to update management/networking/backend at once >> >> by >> >> using >> >> rolling updates to newer release and then upgrade compute nodes one by >> >> one >> >> to >> >> new release.. I think that [2] provides a general upgrade manual. Is >> >> there >> >> any >> >> document describing how are different OSA releases compatible ? Is >> >> there >> >> any >> >> policy in place about backward compatibility ? >> > >> > >> > As a general rule, OpenStack only supports an online upgrade of one >> > version >> > at a time. That is, controller nodes running version N can talk to >> > compute >> > nodes running version N-1. >> > >> > If you can tolerate downtime of the API layer, there has been some >> > discussion around "skip-level" upgrades. >> > >> > Chris >> > >> > >> > >> > _______________________________________________ >> > OpenStack-operators mailing list >> > OpenStack-operators@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> Hello, >> >> Having worked on "skip level" upgrades, I can tell you that it's >> simpler to do the upgrades in a row, because it's a more tested path. >> >> Best regards, >> Jean-Philippe Evrard (evrardjp) >> >> _______________________________________________ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > > -- > > > Regards. > > Adam _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators