[openstack-dev] [all][oslo][neutron] Managing oslo-incubator modules after project split
Ihar Hrachyshka
ihrachys at redhat.com
Tue Dec 16 12:27:43 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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.
>
>>
>> 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
>>>
>>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
iQEcBAEBCgAGBQJUkCU/AAoJEC5aWaUY1u57XPgH/jNEpZCqWP0R3CluOLuUHhWp
yzJNSN8hscdfi3+cn65VDhH6iy2lnOsg8SAr/SZ8jk3JRa/ic7QhKQqXatTdcq58
iAmKBij+slngLhTcv0GJtbLPUdUyiKPnE0+TA88P7ijgMrj6OoF3PCzFpYHGv/ra
z0clRdwv9CSnG1S/+wAZlexawt6qnm/M2da6wgHUrVmoNLMsimxtWGN8r9TZISaZ
mf43DMh4+XDt2rFgZ3Pb3tvgyzUshA5rWykQJ6PBXhyQgaNojVrvBsfQpiP1PuTK
BzidEL9jNNoi6BVq3DkMAnVIPHX1bYhO928svWgUCVLEhr9DFnKI2sNIhyPaWqY=
=mt2Z
-----END PGP SIGNATURE-----
More information about the OpenStack-dev
mailing list