Open Stack

On 22/11/18 6:43 PM, Tony Breeds wrote:
>> ### 3 - Maintain a private interface for ThreadingEvent only on stable/rocky
>> impacted projects: oslo.service
>> related reviews:
>> -https://review.openstack.org/619342/
>>
>> pros:
>> - straightforward
>> cons:
>> - Changing the loopingcall module semantics as it is different type
>> - stable only patches
>> - misunderstoud service customer between Threading, eventlet, etc.. and
>> master behavior
> A variation of this (without adding the debtcollector requirement) might
> work as IIUC all versions of oslo.service < 1.32.0 (except 1.31.6) would
> work and doesn't introduce any new policy violations.
> 
> Adding debcollector is great but introduces at least the semver issues
> from option #1

Hey Tony, can you explain the debtcollector issue a bit more? Is it just 
that we generally promise to not adding anything to requirements.txt on 
stable branches? In this case, debtcollector, appears to already be a 
transitive dependency of something that oslo.service already requires 
(it appears in lower-constraints.txt, at least), so I was assuming that 
there wouldn't be any real-world consequences. Does that change things?

TBH it would be trivial to do something equivalent without adding the 
new requirement, so I guess the easiest thing is if I just update the 
patch to do that.

>> ### 4 - Don't use private interface in oslo.service
>> impacted projects: nova
>> related reviews:
>> -https://review.openstack.org/#/c/619360/
>>
>> pros:
>> - straightforward
>> cons:
>> - this could work but it is not the same sematics as before as the type has
>> changed
>> - stable only patches
>> - misunderstoud service customer between Threading, eventlet, etc.. and
>> master behavior
> I think this is more or less the same as Option #3 in terms of impact.
> If that's right it could be acceptable.

It's slightly higher impact, because you wouldn't be able to upgrade 
oslo.service past 1.31.5 and still run the unit tests on old versions of 
Nova. Whereas with option #3 you could just upgrade oslo.service to 
1.31.7, or just upgrade Nova, and either way everything would work.

Not that we shouldn't do this *as well*, but IMHO we still need to do #3.

>> ### 5 - Leave the CPU bug open on rocky
>> impacted projects: oslo.service
>> related reviews: -
>>
>> pros:
>> - Nova project doesn't impacted
>> cons:
>> - reintroduce the CPU issue
>   
> I think if #3, or #4 works we can avoid the revert part of this but
> regardless we're going to need to block 1.31.6 so I've created:
> 
> https://review.openstack.org/#/c/619655/  ; and abandonedhttps://review.openstack.org/#/c/618834/

I think with #4 we wouldn't need to block, but I agree that blocking 
1.31.6 and merging some version of #3 is the better solution.

>> Personally:
>> - I prefer the #4 or the #2 and they seem to be smooth changes without
>> earthquake or anything like this
>> - the #6 seems to be the worst solution on my side
>> - the #1 introduce semver issue and policy violations so I don't think we
>> can continue with it
> I'm  not certain how this is really different to the options already
> presented but I agree anything substantial on stable branches is pretty
> much a non-starter.
>   
>> Thoughts?
> My preference is for a modified version of #3, unless I'm beaten to it

+1

cheers,
Zane.