[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