Option 2 works for me, thanks for figuring this out Ihar and Doug!
On Mon, Dec 15, 2014 at 11:16 AM, Doug Wiegley <do...@a10networks.com> wrote: > > Hi all, > > Ihar and I discussed this on IRC, and are going forward with option 2 > unless someone has a big problem with it. > > Thanks, > Doug > > > On 12/15/14, 8:22 AM, "Doug Wiegley" <do...@a10networks.com> wrote: > > >Hi Ihar, > > > >I’m actually in favor of option 2, but it implies a few things about your > >time, and I wanted to chat with you before presuming. > > > >Maintenance can not involve breaking changes. At this point, the co-gate > >will block it. Also, oslo graduation changes will have to be made in the > >services repos first, and then Neutron. > > > >Thanks, > >doug > > > > > >On 12/15/14, 6:15 AM, "Ihar Hrachyshka" <ihrac...@redhat.com> wrote: > > > >>-----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 >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev