-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 15/12/14 18:57, Doug Hellmann wrote: > There may be a similar problem managing dependencies on libraries > that live outside of either tree. I assume you already decided how > to handle that. Are you doing the same thing, and adding the > requirements to neutron’s lists?
I guess the idea is to keep in neutron-*aas only those oslo-incubator modules that are used there solely (=not used in main repo). I think requirements are a bit easier and should track all direct dependencies in each of the repos, so that in case main repo decides to drop one, neutron-*aas repos are not broken. For requirements, it's different because there is no major burden due to duplicate entries in repos. > > On Dec 15, 2014, at 12:16 PM, 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: >>> > 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 >>> >> >> _______________________________________________ OpenStack-dev >> mailing list OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUkAXVAAoJEC5aWaUY1u57vmsIAJ9tz7MSqQ+j/nfmRyXARfwu KISUKfDHS5V31BaMtgvmHQRx0wUCA45EXAuqrau3hEfMt/u9mpP7rR69FDRluQeZ pZiz9t3igud5e+UWHgsu3Ja5h6MZoF55CjG7jUY6im+NzvvQdi7PeIMHrE8gZ9P4 UHey/QlNEntwUYefDacCMr3aZSCb4y++Cq0wRbZPI0uMAdEBQUYMNP+/eJNfhjny LUn0vEX2zjKaGLap8uuksvptom9HkRo2v6MlCtalrblxtn0MVg38UyVRv/ik7MOD 381tVXfUbDeZVi+v7tUcYdFmW806GfrUm939w4ryY0oGqUElD4Fch0XKsowD51I= =o8HW -----END PGP SIGNATURE----- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
