[kolla-ansible] Upgrading and skipping a release?

Mark Goddard mark at stackhpc.com
Thu Jan 7 08:59:49 UTC 2021


On Wed, 6 Jan 2021 at 15:48, Eric K. Miller <emiller at 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
>



More information about the openstack-discuss mailing list