Open Stack

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-philippe at 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 <haaaad at 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-philippe at evrard.me> wrote:
> >>
> >> On 2 November 2017 at 18:17, Chris Friesen <chris.friesen at 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 at 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 at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >
> >
> >
> > --
> >
> >
> > Regards.
> >
> > Adam
>
> _______________________________________________
> 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/20171106/14eaff5f/attachment.html>