[stable][oslo] Supporting qemu 4.1.0 on stein and older
On Mon, 2019-10-07 at 16:31 +0000, 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?
i suspect the motivation is the fact that distos like RHEL often bump
qemu and libvirt versions in minor releases. so if you deploy Queens on say
rhel 7.5 orignally but you upgraged it to rhel 7.7 over time you would end up
running with a qemu/libvirt that may not have existed when queens was released.
when qemu has broken its public api in the past and that change in behavior
has been addressed in later openstack release disto have often had to backport
that fix to an openstack that was release before that depency existed.
this depends on the distro. canonical for example package qemu and ovs in the ubuntu
cloud archive for each given release i belive so you can go form 18.04.0 to 18.04.1 and
know it wont break your openstack install but on rhel QEMU and kvm are owned by
a sperate team and layered prodcut like openstack consume the output of that team
which follow the RHEL release cycle not the openstack one.
so i expect this to vary per distro.
when a change is backportable upstream that is obviosly perferable. i dont
actully think this need to be fixed in Train GA if a oslo release is done promptly that
can be consumed instead. i expect this to get backported downs stream anyway so if
we can avoid multiple distros doing that and backport it upstream give it backward compatibale
it think that would be preferable.
just my 2 cents