Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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

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)

iQEcBAEBCgAGBQJUkAXVAAoJEC5aWaUY1u57vmsIAJ9tz7MSqQ+j/nfmRyXARfwu
KISUKfDHS5V31BaMtgvmHQRx0wUCA45EXAuqrau3hEfMt/u9mpP7rR69FDRluQeZ
pZiz9t3igud5e+UWHgsu3Ja5h6MZoF55CjG7jUY6im+NzvvQdi7PeIMHrE8gZ9P4
UHey/QlNEntwUYefDacCMr3aZSCb4y++Cq0wRbZPI0uMAdEBQUYMNP+/eJNfhjny
LUn0vEX2zjKaGLap8uuksvptom9HkRo2v6MlCtalrblxtn0MVg38UyVRv/ik7MOD
381tVXfUbDeZVi+v7tUcYdFmW806GfrUm939w4ryY0oGqUElD4Fch0XKsowD51I=
=o8HW
-----END PGP SIGNATURE-----