<div dir="ltr">We had a call between Andrew (@xarses), Vladimir Kuklin (@aglarendil) and myself (@mihgen) today to finally sort out Neutron ML2 integration in Fuel. We didn't have @xenolog on the call, but hopefully he is more or less fine with all below, and kindly request him to confirm :)<div>

Discussed following topics, with an agreement from all participants:</div><div><ol><li>Risks of merging <a href="https://review.openstack.org/#/c/103280" target="_blank" style="font-family:arial,sans-serif;font-size:12.800000190734863px">https://review.openstack.org/#/c/103280</a> (@xarses, upstream puppet module, will further refer as "280")<span style="color:rgb(80,0,80);font-family:arial,sans-serif;font-size:12.800000190734863px"> vs </span><a href="https://review.openstack.org/#/c/103947" target="_blank" style="font-family:arial,sans-serif;font-size:12.800000190734863px">https://review.openstack.org/#/c/103947</a> (@xenolog, extending existing puppet module with ML2 support, will further refer as "947")</li>

<ul><li>We all agree, that 280 is strategically the way to go. It was so by design, and 947 was done only as risk mitigation plan in case if 280 is not ready in time</li><li>Both 280 and 947 were manually verified in combinations of ubuntu/centos/vlan/gre/ha, 280 needs to be verified with nova-network</li>

<li>947 was ready a week ago and considered to be more stable solution</li><li>280 is has much higher risks to introduce regressions, as it is basically rearchitecturing of Neutron puppet module in Fuel</li><li>947 has backward compatibility support with legacy OVS, while 280 doesn't have it at the moment</li>

</ul><li>Mellanox & VMWare NSX dependency on ML2 implementation rebase time</li><ul><li>Rebase itself should not be hard</li><li>It has to be tested and may take up to next WE to do all rebases/testing/fixing</li><li>

As both Mellanox & NSX Neutron pieces are isolated, it can be an exception for merging by next TH</li></ul><li>Discussed sanitize_network_config [1]</li><ul><li>@aglarendil points out that we need to verify input params which puppet receives in advance, before waiting hours of deploy</li>

<li>@mihgen's point of view is that we need to consider each Fuel component as module, and verify output of it with certain input params. So there is no point to verify input in puppet, if it's being verified in output of Nailgun.</li>

<li>@xarses says that we need to verify configuration files created in system after module execution, to check if it matches with module input params</li><li>Overall topic has been discussed much more extensively, and it needs further follow up. @aglarendil confirms that it is Ok to remove sanitize for now, but start writing much more tests to check that 280 deploys correctly right away</li>

</ul></ol><div>Action plan we've come up with:</div><div><ol><li>Merge 947, as less risky at the moment, also considering the fact that 280 doesn't pass CI</li><ul><li>this will immediately unblock Mellanox & NSX teams so they can rebase on ML2 implementation</li>

</ul><li>In parallel, create a test plan for 280 together with QA team</li><li>@xenolog to join 280's effort, start fixing issues discovered there, including [2]</li><li>Build an ISO, based on 280, and start testing it according to the plan</li>

<li>Merge 280 once test plan is executed and issues fixed. Expected on Monday.</li></ol></div><div>[1] <a href="https://review.openstack.org/#/c/99807/1/specs/5.1/ml2-neutron.rst">https://review.openstack.org/#/c/99807/1/specs/5.1/ml2-neutron.rst</a></div>

<div>[2] <a href="https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_ubuntu/1608/">https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_ubuntu/1608/</a></div><div><br></div><div>Thanks,</div>

</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 9, 2014 at 10:31 PM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<span style="font-family:arial,sans-serif;font-size:13px">Teams from MElanox and VMware based their work on current implementation of Neutron</span></blockquote></div>
Mlnx appears to not set any neutron settings, so wont be enabled correctly with out some more TLC<div>( <a href="https://wiki.openstack.org/wiki/Mellanox-Neutron-Icehouse-Redhat#Neutron_Server_Node" target="_blank">https://wiki.openstack.org/wiki/Mellanox-Neutron-Icehouse-Redhat#Neutron_Server_Node</a> )<br>


<div><br></div></div><div>NSX appears to be using legacy OVS, but assumes just whatever the default core_plugin is so it will need some TLC too.</div><div class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<ul style="font-family:arial,sans-serif;font-size:13px"><li style="margin-left:15px">to merge <a href="https://review.openstack.org/#/c/103280" target="_blank">https://review.openstack.org/#/c/103280</a> in fuel-5.1</li>

</ul>
</blockquote></div><div>Link is wrong should be <a href="https://review.openstack.org/#/c/103947" target="_blank">https://review.openstack.org/#/c/103947</a></div><div class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<ul style="font-family:arial,sans-serif;font-size:13px"><li style="margin-left:15px">To base Neutron implementation for 6.0 get <a href="https://review.openstack.org/#/c/103280/" target="_blank">https://review.openstack.org/#/c/103280/</a> and start working for adapt this for Juno Neutron.</li>


</ul></blockquote></div><div>I still think we should merge it </div><div class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<ul style="font-family:arial,sans-serif;font-size:13px"><li style="margin-left:15px">Also we should discuss how to make HA-wrapper more pluggable.</li></ul></blockquote></div><div><a href="https://review.openstack.org/#/c/103279/" target="_blank">https://review.openstack.org/#/c/103279/</a> makes it very pluggable, and felt like the best start, what else do we need to add in the near term? Should we just extend it as we move more components to it?<br>


</div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Wed, Jul 9, 2014 at 9:21 AM, Sergey Vasilenko <span dir="ltr"><<a href="mailto:svasilenko@mirantis.com" target="_blank">svasilenko@mirantis.com</a>></span> wrote:<br>


</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra">







<p>After review <a href="https://review.openstack.org/#/c/103280/" target="_blank"><span>https://review.openstack.org/#/c/103280/</span></a> I have following thoughts. This patch looks fine, but huge and has lot of changes in deployment logic. Parallel teams work (vmware, melanox) depends on current implementation of Neutron in FUEL. I have a some dreads, that they can’t refactor his code in the short time remaining.</p>





<p>Implementation <a href="https://review.openstack.org/#/c/103280" target="_blank">https://review.openstack.org/#/c/103280</a> has considerably less changes in current code of FUEL. Teams from MElanox and VMware based their work on current implementation of Neutron. Also this implementation was already tested in most deployment modes.</p>





<p>On this basis, I suggest:</p>
<ul>
<li>to merge <a href="https://review.openstack.org/#/c/103280" target="_blank">https://review.openstack.org/#/c/103280</a> in fuel-5.1</li>
<li>To base Neutron implementation for 6.0 get <a href="https://review.openstack.org/#/c/103280/" target="_blank"><span>https://review.openstack.org/#/c/103280/</span></a> and start working for adapt this for Juno Neutron.</li>





<li>Also we should discuss how to make HA-wrapper more pluggable.</li>
</ul></div></div>
<br></div></div><div class="">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></div></blockquote></div><div class=""><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Andrew<div>Mirantis</div><div>Ceph community</div></div>
</div></div>
<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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Mike Scherbakov<br>#mihgen<br><br></div>
</div>