Open Stack

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.