Open Stack

On 21/11/18 2:50 PM, Sean Mooney wrote:
> 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/)?

This is the worst option, because you won't be able to use either an 
older nova with a newer oslo.service, nor an older oslo.service with a 
newer nova.

In fact, if I'm interpreting Matt's comment on 
https://review.openstack.org/619246 correctly, then this may be a 
non-starter because increasing lower-constraints is not allowed on 
stable branches.

>>> 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)?

This is marginally better, provided that it's done in a 
backwards-compatible way (i.e. that doesn't require bumping the 
lower-constraints like https://review.openstack.org/619246 and 
https://review.openstack.org/619022 do). Here's an example that should 
do the trick:

https://review.openstack.org/619360

However, this does still mean that you can't use an older Nova with a 
newer oslo.service. Which is bound to cause trouble for somebody.

It also relies on a different private interface, although we're less 
likely to need to change this one in stable/rocky.

>> 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

Surely being able to update oslo.service and nova independently is 
objectively better than having to upgrade them in lock-step.

Would it make you feel better if this patch were also on master? Why?

> 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.

This is a fair point; only the clear()/wait()/stop() methods are the 
same. is_running() changes to is_set() and done() changes to set(). So 
it is a bit hacky. But it still solves the instance of the problem we 
know about (and FWIW any instance of the problem that *could*, in 
principle, be solved by the fixture).

> 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.
>>>
>>
>>