[openstack-dev] [all][oslo][neutron] Managing oslo-incubator modules after project split

Ihar Hrachyshka ihrachys at redhat.com
Mon Dec 15 14:15:41 UTC 2014

Hash: SHA512

Hi all,

the question arose recently in one of reviews for neutron-*aas repos
to remove all oslo-incubator code from those repos since it's
duplicated in neutron main repo. (You can find the link to the review
at the end of the email.)

Brief hostory: neutron repo was recently split into 4 pieces (main,
neutron-fwaas, neutron-lbaas, and neutron-vpnaas). The split resulted
in each repository keeping their own copy of
neutron/openstack/common/... tree (currently unused in all
neutron-*aas repos that are still bound to modules from main repo).

As a oslo liaison for the project, I wonder what's the best way to
manage oslo-incubator files. We have several options:

1. just kill all the neutron/openstack/common/ trees from neutron-*aas
repositories and continue using modules from main repo.

2. kill all duplicate modules from neutron-*aas repos and leave only
those that are used in those repos but not in main repo.

3. fully duplicate all those modules in each of four repos that use them.

I think option 1. is a straw man, since we should be able to introduce
new oslo-incubator modules into neutron-*aas repos even if they are
not used in main repo.

Option 2. is good when it comes to synching non-breaking bug fixes (or
security fixes) from oslo-incubator, in that it will require only one
sync patch instead of e.g. four. At the same time there may be
potential issues when synchronizing updates from oslo-incubator that
would break API and hence require changes to each of the modules that
use it. Since we don't support atomic merges for multiple projects in
gate, we will need to be cautious about those updates, and we will
still need to leave neutron-*aas repos broken for some time (though
the time may be mitigated with care).

Option 3. is vice versa - in theory, you get total decoupling, meaning
no oslo-incubator updates in main repo are expected to break
neutron-*aas repos, but bug fixing becomes a huge PITA.

I would vote for option 2., for two reasons:
- - most oslo-incubator syncs are non-breaking, and we may effectively
apply care to updates that may result in potential breakage (f.e.
being able to trigger an integrated run for each of neutron-*aas repos
with the main sync patch, if there are any concerns).
- - it will make oslo liaison life a lot easier. OK, I'm probably too
selfish on that. ;)
- - it will make stable maintainers life a lot easier. The main reason
why stable maintainers and distributions like recent oslo graduation
movement is that we don't need to track each bug fix we need in every
project, and waste lots of cycles on it. Being able to fix a bug in
one place only is *highly* anticipated. [OK, I'm quite selfish on that
one too.]
- - it's a delusion that there will be no neutron-main syncs that will
break neutron-*aas repos ever. There can still be problems due to
incompatibility between neutron main and neutron-*aas code resulted
EXACTLY because multiple parts of the same process use different
versions of the same module.

That said, Doug Wiegley (lbaas core) seems to be in favour of option
3. due to lower coupling that is achieved in that way. I know that
lbaas team had a bad experience due to tight coupling to neutron
project in the past, so I appreciate their concerns.

All in all, we should come up with some standard solution for both
advanced services that are already split out, *and* upcoming vendor
plugin shrinking initiative.

The initial discussion is captured at:

Version: GnuPG/MacGPG2 v2.0.22 (Darwin)


More information about the OpenStack-dev mailing list