Open Stack

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:
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA512
>>
>>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
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>>
>>iQEcBAEBCgAGBQJUju0NAAoJEC5aWaUY1u57n5YH/jA4l5DsLgRpw9gYsoSWVGvh
>>apmJ4UlnAKhxzc787XImz1VA+ztSyIwAUdEdcfq3gkinP58q7o48oIXOGjFXaBNq
>>6qBePC1hflEqZ85Hm4/i5z51qutjW0dyi4y4C6FHgM5NsEkhbh0QIa/u8Hr4F1q6
>>tkr0kDbCbDkiZ8IX1l74VGWQ3QvCNeJkANUg79BqGq+qIVP3BeOHyWqRmpLZFQ6E
>>QiUwhiYv5l4HekCEQN8PWisJoqnhbTNjvLBnLD82IitLd5vXnsXfSkxKhv9XeOg/
>>czLUCyr/nJg4aw8Qm0DTjnZxS+BBe5De0Ke4zm2AGePgFYcai8YQPtuOfSJDbXk=
>>=D6Gn
>>-----END PGP SIGNATURE-----
>