-----BEGIN PGP SIGNED MESSAGE----- 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: https://review.openstack.org/#/c/141427/ Thanks, /Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUju0NAAoJEC5aWaUY1u57n5YH/jA4l5DsLgRpw9gYsoSWVGvh apmJ4UlnAKhxzc787XImz1VA+ztSyIwAUdEdcfq3gkinP58q7o48oIXOGjFXaBNq 6qBePC1hflEqZ85Hm4/i5z51qutjW0dyi4y4C6FHgM5NsEkhbh0QIa/u8Hr4F1q6 tkr0kDbCbDkiZ8IX1l74VGWQ3QvCNeJkANUg79BqGq+qIVP3BeOHyWqRmpLZFQ6E QiUwhiYv5l4HekCEQN8PWisJoqnhbTNjvLBnLD82IitLd5vXnsXfSkxKhv9XeOg/ czLUCyr/nJg4aw8Qm0DTjnZxS+BBe5De0Ke4zm2AGePgFYcai8YQPtuOfSJDbXk= =D6Gn -----END PGP SIGNATURE----- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev