Open Stack

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