The Neutron OVS agent should not cause interrupts on restart in the later versions (Liberty+ https://review.openstack.org/#/c/215596/) of OpenStack since they don't destroy old flows until the new ones are setup so you should be able to safely do that.
On Fri, Nov 3, 2017 at 9:22 AM, Jean-Philippe Evrard < jean-phili...@evrard.me> wrote: > 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 >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
