Open Stack

> 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