On Thu, Nov 22, 2018 at 05:58:08PM +0100, Herve Beraud wrote:
Just a tiny report to summarize the situation to offer a big picture and to analyze proposed solutions since peoples have submits new patches and some other people have shared their opinions.
Each solution contains the impacted projects, the related gerrit reviews, pro/cons.
### 1 - Backport master changer and also backport new feature into a stable branch impacted projects: oslo.service, nova related reviews: - https://review.openstack.org/617989 - https://review.openstack.org/619022 - https://review.openstack.org/619019
pros: - follow the master changes - just use a backport cons: - backport a new feature into a stable branch and then this a violation of the stable policy - introduce a semver minor bump and a version 1.32 already exist - won't be able to use either an older nova with a newer oslo.service - increasing lower-constraints is not allowed on stable branches - vendors need to ensure that there is a 'fixture' package available
My position is that this is a non-starter.
### 2 - Update the nova test to mock the new private interface impacted projects: nova reviews: - https://review.openstack.org/619246
pros: - straightforward cons: - still mocking a private inferface - stable only patches
This one is also a stable policy issue in that it forces nova to require a newer version of oslo.service and IIUC will never land as this approach can never be compatible with both oslo.service < 1.31.6 and 1.31.6
### 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
### 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.
### 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 abandoned https://review.openstack.org/#/c/618834/
### 6 - Revert CPU fix and totally rework it into someting that doesn't break the Nova CI impacted projects: oslo.service related reviews: -
pros: - Nova project doesn't impacted cons: - potentially introduce more rewrites in the futures that depends on fix on oslo.service loopingcall master - stable only patches - increase potential backport difficulties on oslo.service upstream and downstream - increase work load on upstream and downstream
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 I'll create a matrix that tests old and new olso.service against old and new nova to ensure that we're not missing something.
I hope this summarize help you to have a better overview :)
Thanks!
I hope I have not forgotten anything and if so I apologize in advance.
Really appreciate you keeping this on track and pulling the information together. Thanks! Tony.