On Dec 16, 2014, at 5:13 AM, Ihar Hrachyshka <[email protected]> wrote:
> Signed PGP part > 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). How are the *aas packages installed? Are they separate libraries or applications that are installed on top of neutron? Or are their files copied into the neutron namespace? > > 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 <[email protected]> > > 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" <[email protected]> > >> 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" <[email protected]> > >>> 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 [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
