Open Stack

On 12/16/14, 2:41 PM, "Doug Hellmann" <doug at doughellmann.com> wrote:

>
>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?

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
>> >>> <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
>> >>>
>> >>
>> >
>> 
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev