-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 16/12/14 13:41, Doug Hellmann wrote: > > 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?
Yes, neutron is in their requirements.txt files. > >> >>> >>>> >>>> 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) iQEcBAEBCgAGBQJUkCy3AAoJEC5aWaUY1u57Fk4IAOM2BpwcqlOgfxMtvcjfNpHB IfFQgAalsI0uzycL9hbArYP66ZcTzDSSIX7DNndTIAHwDAvoEtOJ+WVqFm3jH9Tr WHiTy0tx1nkzyE4oGZdp1DAYg2LEPuNn3tbC8ROqUnIqFrZ0voMKuhTGOCe4cNWL L+lljW6H1r5DZVm56gk9HsJHYwrmMYfY8YiQ5AH+j6w5rlu2a4Y6VtlDsWGZWBL4 kmnfhzjZLUnuJ3CBlbClApsJOh54dDjVgJkHxoLgGnKVzLptoXEn+0IcMippe4AR SFGcF9NAuugXgJqJlICfDVcFF6VgsQXmoC99Cq4L1EOaGdsF91SYvrEZ3JTlOTM= =d/+5 -----END PGP SIGNATURE----- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
