[kolla-ansible] Upgrading and skipping a release?
Hi, We're working on some upgrades of OpenStack deployed with Kolla Ansible (Stein and later), and wasn't sure if it was practical or possible to upgrade, say, from Stein to Victoria, or Train to Victoria, directly, instead of upgrading in 3 steps from Stein->Train->Ussuri->Victoria. Any reason skipping a release will cause any known harm? Anybody done this successfully? Thanks! Eric
On Wed, 6 Jan 2021 at 01:45, Eric K. Miller <emiller@genesishosting.com> wrote:
Hi,
We're working on some upgrades of OpenStack deployed with Kolla Ansible (Stein and later), and wasn't sure if it was practical or possible to upgrade, say, from Stein to Victoria, or Train to Victoria, directly, instead of upgrading in 3 steps from Stein->Train->Ussuri->Victoria. Any reason skipping a release will cause any known harm? Anybody done this successfully?
Hi Eric. What you're referring to is a fast-forward upgrade [1]. This is not officially supported by Kolla Ansible, and not something we test upstream. There was an effort a few years ago to implement it, but it stalled. The test matrix does increase somewhat when you allow FFUs, which is why I believe many projects such as Tripleo define supported FFU jumps. One thing in particular that may catch you out is some DB migrations or cleanup processes that happen at runtime may not get executed. In short, I'd suggest going one release at a time. It's a pain, but upgrades in Kolla are relatively sane. [1] https://wiki.openstack.org/wiki/Fast_forward_upgrades#:~:text=9%20Gotchas-,W.... Mark
Thanks!
Eric
Hi Eric. What you're referring to is a fast-forward upgrade [1]. This is not officially supported by Kolla Ansible, and not something we test upstream. There was an effort a few years ago to implement it, but it stalled. The test matrix does increase somewhat when you allow FFUs, which is why I believe many projects such as Tripleo define supported FFU jumps. One thing in particular that may catch you out is some DB migrations or cleanup processes that happen at runtime may not get executed.
In short, I'd suggest going one release at a time. It's a pain, but upgrades in Kolla are relatively sane.
Thank you mark! Much appreciated. We were hoping to avoid any potential pitfalls with the Python 2.x to 3.x transition, but it looks like we need to simply test quick upgrades from one to the next. Regarding the QEMU/KVM kernel module version on the host, I'm assuming we need to plan for VM shutdown/restart since I "think" we may need a newer version for Ussuri or Victoria. Looks like we're running: (on CentOS 7) Compiled against library: libvirt 4.5.0 Using library: libvirt 4.5.0 Using API: QEMU 4.5.0 Running hypervisor: QEMU 2.12.0 Out of curiosity, have you used CloudLinux' KernelCare or any other hot-swap kernel module components to avoid downtime of a KVM host? Eric
On Wed, 6 Jan 2021 at 15:48, Eric K. Miller <emiller@genesishosting.com> wrote:
Hi Eric. What you're referring to is a fast-forward upgrade [1]. This is not officially supported by Kolla Ansible, and not something we test upstream. There was an effort a few years ago to implement it, but it stalled. The test matrix does increase somewhat when you allow FFUs, which is why I believe many projects such as Tripleo define supported FFU jumps. One thing in particular that may catch you out is some DB migrations or cleanup processes that happen at runtime may not get executed.
In short, I'd suggest going one release at a time. It's a pain, but upgrades in Kolla are relatively sane.
Thank you mark! Much appreciated. We were hoping to avoid any potential pitfalls with the Python 2.x to 3.x transition, but it looks like we need to simply test quick upgrades from one to the next.
Regarding the QEMU/KVM kernel module version on the host, I'm assuming we need to plan for VM shutdown/restart since I "think" we may need a newer version for Ussuri or Victoria. Looks like we're running:
(on CentOS 7) Compiled against library: libvirt 4.5.0 Using library: libvirt 4.5.0 Using API: QEMU 4.5.0 Running hypervisor: QEMU 2.12.0
If you are running CentOS then the CentOS 8 upgrade is quite involved. See https://docs.openstack.org/kolla-ansible/train/user/centos8.html. You won't need to worry about qemu/kvm versions if you migrate VMs from CentOS 7 to 8 host as you go.
Out of curiosity, have you used CloudLinux' KernelCare or any other hot-swap kernel module components to avoid downtime of a KVM host?
Haven't tried it.
Eric
participants (2)
-
Eric K. Miller
-
Mark Goddard