<div dir="ltr">Option 2 works for me, thanks for figuring this out Ihar and Doug!<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 15, 2014 at 11:16 AM, Doug Wiegley <span dir="ltr"><<a href="mailto:dougw@a10networks.com" target="_blank">dougw@a10networks.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Ihar and I discussed this on IRC, and are going forward with option 2<br>
unless someone has a big problem with it.<br>
<br>
Thanks,<br>
Doug<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 12/15/14, 8:22 AM, "Doug Wiegley" <<a href="mailto:dougw@a10networks.com">dougw@a10networks.com</a>> wrote:<br>
<br>
>Hi Ihar,<br>
><br>
>I’m actually in favor of option 2, but it implies a few things about your<br>
>time, and I wanted to chat with you before presuming.<br>
><br>
>Maintenance can not involve breaking changes. At this point, the co-gate<br>
>will block it.  Also, oslo graduation changes will have to be made in the<br>
>services repos first, and then Neutron.<br>
><br>
>Thanks,<br>
>doug<br>
><br>
><br>
>On 12/15/14, 6:15 AM, "Ihar Hrachyshka" <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>> wrote:<br>
><br>
>>-----BEGIN PGP SIGNED MESSAGE-----<br>
>>Hash: SHA512<br>
>><br>
>>Hi all,<br>
>><br>
>>the question arose recently in one of reviews for neutron-*aas repos<br>
>>to remove all oslo-incubator code from those repos since it's<br>
>>duplicated in neutron main repo. (You can find the link to the review<br>
>>at the end of the email.)<br>
>><br>
>>Brief hostory: neutron repo was recently split into 4 pieces (main,<br>
>>neutron-fwaas, neutron-lbaas, and neutron-vpnaas). The split resulted<br>
>>in each repository keeping their own copy of<br>
>>neutron/openstack/common/... tree (currently unused in all<br>
>>neutron-*aas repos that are still bound to modules from main repo).<br>
>><br>
>>As a oslo liaison for the project, I wonder what's the best way to<br>
>>manage oslo-incubator files. We have several options:<br>
>><br>
>>1. just kill all the neutron/openstack/common/ trees from neutron-*aas<br>
>>repositories and continue using modules from main repo.<br>
>><br>
>>2. kill all duplicate modules from neutron-*aas repos and leave only<br>
>>those that are used in those repos but not in main repo.<br>
>><br>
>>3. fully duplicate all those modules in each of four repos that use them.<br>
>><br>
>>I think option 1. is a straw man, since we should be able to introduce<br>
>>new oslo-incubator modules into neutron-*aas repos even if they are<br>
>>not used in main repo.<br>
>><br>
>>Option 2. is good when it comes to synching non-breaking bug fixes (or<br>
>>security fixes) from oslo-incubator, in that it will require only one<br>
>>sync patch instead of e.g. four. At the same time there may be<br>
>>potential issues when synchronizing updates from oslo-incubator that<br>
>>would break API and hence require changes to each of the modules that<br>
>>use it. Since we don't support atomic merges for multiple projects in<br>
>>gate, we will need to be cautious about those updates, and we will<br>
>>still need to leave neutron-*aas repos broken for some time (though<br>
>>the time may be mitigated with care).<br>
>><br>
>>Option 3. is vice versa - in theory, you get total decoupling, meaning<br>
>>no oslo-incubator updates in main repo are expected to break<br>
>>neutron-*aas repos, but bug fixing becomes a huge PITA.<br>
>><br>
>>I would vote for option 2., for two reasons:<br>
>>- - most oslo-incubator syncs are non-breaking, and we may effectively<br>
>>apply care to updates that may result in potential breakage (f.e.<br>
>>being able to trigger an integrated run for each of neutron-*aas repos<br>
>>with the main sync patch, if there are any concerns).<br>
>>- - it will make oslo liaison life a lot easier. OK, I'm probably too<br>
>>selfish on that. ;)<br>
>>- - it will make stable maintainers life a lot easier. The main reason<br>
>>why stable maintainers and distributions like recent oslo graduation<br>
>>movement is that we don't need to track each bug fix we need in every<br>
>>project, and waste lots of cycles on it. Being able to fix a bug in<br>
>>one place only is *highly* anticipated. [OK, I'm quite selfish on that<br>
>>one too.]<br>
>>- - it's a delusion that there will be no neutron-main syncs that will<br>
>>break neutron-*aas repos ever. There can still be problems due to<br>
>>incompatibility between neutron main and neutron-*aas code resulted<br>
>>EXACTLY because multiple parts of the same process use different<br>
>>versions of the same module.<br>
>><br>
>>That said, Doug Wiegley (lbaas core) seems to be in favour of option<br>
>>3. due to lower coupling that is achieved in that way. I know that<br>
>>lbaas team had a bad experience due to tight coupling to neutron<br>
>>project in the past, so I appreciate their concerns.<br>
>><br>
>>All in all, we should come up with some standard solution for both<br>
>>advanced services that are already split out, *and* upcoming vendor<br>
>>plugin shrinking initiative.<br>
>><br>
>>The initial discussion is captured at:<br>
>><a href="https://review.openstack.org/#/c/141427/" target="_blank">https://review.openstack.org/#/c/141427/</a><br>
>><br>
>>Thanks,<br>
>>/Ihar<br>
>>-----BEGIN PGP SIGNATURE-----<br>
>>Version: GnuPG/MacGPG2 v2.0.22 (Darwin)<br>
>><br>
>>iQEcBAEBCgAGBQJUju0NAAoJEC5aWaUY1u57n5YH/jA4l5DsLgRpw9gYsoSWVGvh<br>
>>apmJ4UlnAKhxzc787XImz1VA+ztSyIwAUdEdcfq3gkinP58q7o48oIXOGjFXaBNq<br>
>>6qBePC1hflEqZ85Hm4/i5z51qutjW0dyi4y4C6FHgM5NsEkhbh0QIa/u8Hr4F1q6<br>
>>tkr0kDbCbDkiZ8IX1l74VGWQ3QvCNeJkANUg79BqGq+qIVP3BeOHyWqRmpLZFQ6E<br>
>>QiUwhiYv5l4HekCEQN8PWisJoqnhbTNjvLBnLD82IitLd5vXnsXfSkxKhv9XeOg/<br>
>>czLUCyr/nJg4aw8Qm0DTjnZxS+BBe5De0Ke4zm2AGePgFYcai8YQPtuOfSJDbXk=<br>
>>=D6Gn<br>
>>-----END PGP SIGNATURE-----<br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div></div>