Open Stack

On 10/7/19 11:31 AM, Jeremy Stanley wrote:
> On 2019-10-07 10:44:04 -0500 (-0500), Ben Nemec wrote:
> [...]
>> Qemu 4.1.0 did not exist during the Stein cycle, so it's not clear
>> to me that backporting bug fixes for it is valid. The original
>> author of the patch actually wants it for Rocky
> [...]
> 
> Neither the changes nor the bug report indicate what the motivation
> is for supporting newer Qemu with (much) older OpenStack. Is there
> some platform which has this Qemu behavior on which folks are trying
> to run Rocky? Or is it a homegrown build combining these dependency
> versions from disparate time periods? Or maybe some other reason I'm
> not imagining?
> 

In addition to the downstream reasons Sean mentioned, Mark (the original 
author of the patch) responded to my question on the train backport with 
this:

"""
Today, I need it in Rocky. But, I'm find to do local patching.

Anybody who needs Qemu 4.1.0 likely needs it. A key feature in Qemu 
4.1.0 is that this is the first release of Qemu to include proper 
support for migration of L1 guests that have L2 guests (nVMX / nested 
KVM). So, I expect it is pretty important to whoever realizes this, and 
whoever needs this.
"""

So basically a desire to use a feature of the newer qemu with older 
openstack, which is why I'm questioning whether this fits our stable 
policy. My inclination is to say it's a fairly simple, 
backward-compatible patch that will make users' lives easier, but I also 
feel like doing a backport to enable a feature, even if the actual patch 
is a "bugfix", is violating the spirit of the stable policy.