[openstack-dev] [nova][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

Matt Riedemann mriedem at linux.vnet.ibm.com
Tue Sep 20 21:21:22 UTC 2016


On 9/20/2016 4:17 PM, Matt Riedemann wrote:
> On 9/20/2016 7:38 AM, Alan Pevec wrote:
>> 2016-09-20 13:27 GMT+02:00 Kashyap Chamarthy <kchamart at redhat.com>:
>>>>   (3) Do nothing, leave the bug unfixed in stable/liberty
>>>
>>> That was the unspoken third option, thanks for spelling it out. :-)
>>
>> Yes, let's abandon both reviews.
>>
>> Cheers,
>> Alan
>>
>> __________________________________________________________________________
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> I'd rather not bump the minimum on oslo.concurrency given the transitive
> dependencies that would be pulled in which required higher minimums.
>
> So if I had to choose I'd go with the nova backport with the workaround:
>
> https://review.openstack.org/#/c/327624/
>
> Which logs an error if you don't have a new enough oslo.concurrency.
>
> But I'm also fine with just considering this a latent bug as danpb
> pointed out and let downstream packagers/vendors handle it as they see fit.
>

BTW, with my downstream hat on, if I were backporting this and packaging 
it, I'd personally cherry pick the oslo.concurrency fix that is required 
to whatever version of oslo.concurrency we shipped in each release and 
bump the patch version on our rpm. Then patch the nova fix in and make 
the nova rpm dependent on that patched oslo.concurrency rpm version. But 
that's just me. We were constrained by legal approval on which versions 
of something we could ship, and after a release those were basically 
frozen, so we couldn't just pick up new minimums and would workaround 
that by patching in the fixes we actually needed and tied the dependent 
versions between the rpms.

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list