Open Stack

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20181123/480be14e/attachment.sig>