Open Stack

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

On 16/12/14 13:41, Doug Hellmann 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?

Yes, neutron is in their requirements.txt files.

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

iQEcBAEBCgAGBQJUkCy3AAoJEC5aWaUY1u57Fk4IAOM2BpwcqlOgfxMtvcjfNpHB
IfFQgAalsI0uzycL9hbArYP66ZcTzDSSIX7DNndTIAHwDAvoEtOJ+WVqFm3jH9Tr
WHiTy0tx1nkzyE4oGZdp1DAYg2LEPuNn3tbC8ROqUnIqFrZ0voMKuhTGOCe4cNWL
L+lljW6H1r5DZVm56gk9HsJHYwrmMYfY8YiQ5AH+j6w5rlu2a4Y6VtlDsWGZWBL4
kmnfhzjZLUnuJ3CBlbClApsJOh54dDjVgJkHxoLgGnKVzLptoXEn+0IcMippe4AR
SFGcF9NAuugXgJqJlICfDVcFF6VgsQXmoC99Cq4L1EOaGdsF91SYvrEZ3JTlOTM=
=d/+5
-----END PGP SIGNATURE-----