On Dec 16, 2014, at 7:27 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
> Signed PGP part > On 16/12/14 12:50, Doug Hellmann wrote: > > > > On Dec 16, 2014, at 5:13 AM, Ihar Hrachyshka <ihrac...@redhat.com> > > 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? > > > > >> > >> 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 > >>> > >> > > > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
