On Tue, Sep 20, 2016 at 11:57:26AM +0100, Daniel P. Berrange wrote: > On Tue, Sep 20, 2016 at 12:48:49PM +0200, Kashyap Chamarthy wrote: > > The said patch in question fixes a CVE[x] in stable/liberty. > > > > We currently have two options, both of them have caused an impasse with > > the Nova upstream / stable maintainers. We've had two-ish months to > > mull over this. I'd prefer to get this out of a limbo, & bring this to > > a logical conclusion. > > > > The two options at hand: > > > > (1) Nova backport from master (that also adds a check for the presence > > of 'ProcessLimits' attribute which is only present in > > oslo.concurrency>=2.6.1; and a conditional check for 'prlimit' > > parameter in qemu_img_info() method.) > > > > https://review.openstack.org/#/c/327624/ -- "virt: set address space > > & CPU time limits when running qemu-img" > > > > (2) Or bump global-requirements for 'oslo.concurrency' > > > > https://review.openstack.org/#/c/337277/5 -- Bump > > 'global-requirements' for 'oslo.concurrency' to 2.6.1 > > Actually we have 3 options > > (3) Do nothing, leave the bug unfixed in stable/liberty > > While this is a security bug, it is one that has existed in every single > openstack release ever, and it is not a particularly severe bug. Even if > we fixed in liberty, it would still remain unfixed in every release before > liberty. We're in the verge of releasing Newton at which point liberty > becomes less relevant. So I question whether it is worth spending more > effort on dealing with this in liberty upstream. Downstream vendors > still have the option to do either (1) or (2) in their own private > branches if they so desire, regardless of whether we fix it upstream.
I think 3 is the least worst option. If we're going to do something else then it'd need to be (1). I feel like we need to rule out (2). I'll hack something up in the requirements repo to show that the try/except does what is needed which oslo.concurrency is < 2.6.1 Yours Tony.
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev