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.