[Openstack-operators] Openstack release compatibility

Jean-Philippe Evrard jean-philippe at evrard.me
Fri Nov 3 16:22:57 UTC 2017


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



More information about the OpenStack-operators mailing list