[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