Open Stack

Okay, circling back to wrap this topic up. It sounds like this is a 
pretty big win in terms of avoiding random failures either from trying 
to migrate a VM with nested guests on older qemu or using newer qemu 
with older OpenStack. Since it's a pretty simple patch and it allows our 
stable branches to behave more sanely, I'm inclined to go with the 
backport. If anyone strongly objects, please let me know ASAP before we 
release it.

On 10/7/19 3:36 PM, Ben Nemec wrote:
> 
> 
> On 10/7/19 3:08 PM, Sean Mooney wrote:
>> On Mon, 2019-10-07 at 14:43 -0500, Ben Nemec wrote:
>>>
>>> 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.
>> in many distros the older qemus allow migration of the l1 guest 
>> eventhouhg it is
>> unsafe to do so and either work by luck or the vm will curput its 
>> memroy and likely
>> crash.  the context of the qemu issue is for years people though that 
>> live migration with
>> nested virt worked, then it was disabeld upstream and many distos 
>> reverted that as it would
>> break there users where they got lucky and it worked, and in 4.1 it 
>> was fixed.
>>
>> this does not add or remvoe any functionality in openstack nova will 
>> try to live migarte if you
>> tell it too regardless of the qemu it has it just will fail if the 
>> live migration check was complied in.
>>
>>
>> similarly if all your images did not have fractional sizes you could 
>> use 4.1.0 with older
>> oslo releases and it would be fine. i.e. you could get lucky and for 
>> your specific usecase this
>> might not be needed but it would be nice not do depend on luck.
>>
>> anyway i woudl expect any disto the chooses to support qemu 4.1.0 to 
>> backport this as required.
>> im not sure this problematic to require a late oslo version bump 
>> before train ga but i would hope
>> it can be fixed on stable/train
> 
> Note that this discussion is separate from the train patch. I agree we 
> should do that backport, and actually we already have. That discussion 
> was just about timing of the release.
> 
> This thread is because the fix was also proposed to stable/stein. It 
> merged before I had a chance to start this discussion, and I'm wondering 
> if we need to revert it.
>