settingsLogin | Registersettings

[Openstack-operators] Openstack release compatibility

0 votes

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 ?

[1] https://etherpad.openstack.org/p/osa-newton-xenial-upgrade
[2] https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime

--

Regards.

Adam


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
asked Nov 11, 2017 in openstack-operators by haad (160 points)  

7 Responses

0 votes

On 31 October 2017 at 07:13, haad haaaad@gmail.com 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 ?

[1] https://etherpad.openstack.org/p/osa-newton-xenial-upgrade
[2] https://wiki.openstack.org/wiki/Upgrade-with-minimal-downtime

--

Regards.

Adam


OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Hello,

I'd advise you to follow the standard OpenStack-Ansible path, which is
upgrading from Mitaka to Newton, then do your ubuntu upgrade to
xenial.
From Newton onwards, we have code taking care of the rolling part of
the upgrade, which should help you getting to Pike, after a series of
upgrades (N->O->P) under ubuntu 16.04.

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
responded Nov 2, 2017 by Jean-Philippe_Evrard (1,360 points)   2
0 votes

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
responded Nov 2, 2017 by Chris_Friesen (20,420 points)   3 13 19
0 votes

On 2 November 2017 at 18:17, Chris Friesen chris.friesen@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
responded Nov 3, 2017 by Jean-Philippe_Evrard (1,360 points)   2
0 votes

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@evrard.me> wrote:

On 2 November 2017 at 18:17, Chris Friesen chris.friesen@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
responded Nov 3, 2017 by haad (160 points)  
0 votes

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@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@evrard.me wrote:

On 2 November 2017 at 18:17, Chris Friesen chris.friesen@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
responded Nov 3, 2017 by Jean-Philippe_Evrard (1,360 points)   2
0 votes

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@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@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@evrard.me wrote:

On 2 November 2017 at 18:17, Chris Friesen <chris.friesen@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
responded Nov 6, 2017 by kevin_at_benton.pub (15,600 points)   2 3 4
0 votes

Hello,

OpenStack-Ansible Mitaka deploys Linux Bridge by default.
This would still happen, but as said, it's not too big of a deal too.

Best regards,
Jean-Philippe (evrardjp)

On 6 November 2017 at 08:10, Kevin Benton kevin@benton.pub wrote:
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@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@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@evrard.me wrote:

On 2 November 2017 at 18:17, Chris Friesen
chris.friesen@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
responded Nov 11, 2017 by Jean-Philippe_Evrard (1,360 points)   2
...