On 12/16/14, 2:41 PM, "Doug Hellmann" <[email protected]> wrote:
> >On Dec 16, 2014, at 7:27 AM, Ihar Hrachyshka <[email protected]> wrote: > >> Signed PGP part >> On 16/12/14 12:50, Doug Hellmann wrote: >> > >> > 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? >> >> They are separate libraries with their own setup.py, dependencies, >> tarballs, all that, but they are free to use (public) code from main >> neutron package. > >OK. > >If they don¹t have copies of all of the incubated modules they use, how >are they tested? Is neutron a dependency? This is/was one of my concerns with the decomposition proposal. It is not clear if neutron is a dependency. My two cents is that it should be. > >> >> > >> >> >> >> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
