Open Stack

On Dec 16, 2014, at 7:27 AM, Ihar Hrachyshka <ihrachys at 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 <ihrachys at 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
> >>> <dougw at 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" <dougw at 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"
> >>>>> <ihrachys at 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 at lists.openstack.org
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>
> >
>