[oslo][nova][stable][requirements] Fixing a high CPU usage from oslo.service into stable/rocky branch

Sean Mooney smooney at redhat.com
Wed Nov 21 19:50:13 UTC 2018


On Wed, 2018-11-21 at 14:38 -0500, Zane Bitter wrote:
> On 21/11/18 9:47 AM, Herve Beraud wrote:
> > # Questions and proposed solutions
> > 
> > This thread try to summarize the current situation.
> > 
> > We need to find how to be able to proceed, so this thread aim to allow 
> > to discuss between team to find the best way to fix.
> > 
> > 1. Do we need to continue to try to backport fixture on oslo.service to 
> > fix the CI problem (https://review.openstack.org/#/c/617989/)?
> > 
> > 2. Do we need to find an another approach like mocking 
> > oslo.service.loopingcall._Event.wait in nova instead of mocking 
> > oslo_service.loopingcall._ThreadingEvent.wait (example: 
> > https://review.openstack.org/#/c/616697/2/nova/tests/unit/compute/test_compute_mgr.py)? 
> 
> 3. Doesn't this get solved if we add a line like:
> 
>    _ThreadingEvent = _Event
> 
> in oslo.service on stable/rocky? That seems harmless and the easiest way 
> to maintain the same sort-of-public interface so nothing else ought to 
> break either. And with no change in Nova people won't need to worry 
> about needing to update oslo.service at the same time they update Nova 
> to avoid breakage.
> 
> Here's a patch: https://review.openstack.org/619342
a stable only patch is not really any better in my view then 2
you are also chaning the loopingcall modules semantics
as it is a different type even if you are allowing previously syntaxly
vaild code to execute it does not maintain backwards compatiblity.

we are not using a staticaly compiled language so we dont need to consider
abi breakage this would result in for c or c++ but it i would stonglely prefer 1 or 2.

> 
> cheers,
> Zane.
> 
> > This is only a fix on the nova side and itallowsus to update 
> > oslo.service requirements and allowsus to fix the high CPU usage issue. 
> > I've submit this patch (https://review.openstack.org/619246)who 
> > implement the description above.
> > 
> > Personaly I think we need to find an another approach like the mocking 
> > remplacement (c.f 2).
> > 
> > We need to decide which way we use and to discuss about other solutions.
> > 
> 
> 



More information about the openstack-discuss mailing list