<div dir="ltr">I hope we can sort this out on the mailing list IRC, without having to schedule emergency meetings.<div><br></div><div>Salvatore<div class="gmail_extra"><br><div class="gmail_quote">On 25 March 2014 22:58, Nachi Ueno <span dir="ltr"><<a href="mailto:nachi@ntti3.com" target="_blank">nachi@ntti3.com</a>></span> wrote:<br>
<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">Hi Nova, Neturon Team<br>
<br>
I would like to discuss issue of Neutron + Nova + OVS security group fix.<br>
We have a discussion in IRC today, but the issue is complicated so we will have<br>
a conf call tomorrow 17:00 UST (10AM PDT). #openstack-neutron </blockquote><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">

(I'll put conf call information in IRC)<br></blockquote><div><br></div><div>thanks, but I'd prefer you discuss the matter on IRC.</div><div>I won't be available at that time and having IRC logs on eavesdrop will allow me to catch up without having to ask people or waiting for minutes on the mailing list.</div>
<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">
<br>
<-- Please let me know if this time won't work with you.<br>
<br>
Bug Report<br>
<a href="https://bugs.launchpad.net/neutron/+bug/1297469" target="_blank">https://bugs.launchpad.net/neutron/+bug/1297469</a><br>
<br>
Background of this issue:<br>
ML2 + OVSDriver + IptablesBasedFirewall combination is a default<br>
plugin setting in the Neutron.<br>
In this case, we need a special handing in VIF. Because OpenVSwitch<br>
don't support iptables, we are<br>
using linuxbride + openvswitch bridge. We are calling this as hybrid driver.<br>
<br></blockquote><div><br></div><div>The hybrid solution in Neutron has been around for such a long time that I would hardly call it a "special handling".</div><div>To summarize, the VIF is plugged into a linux bridge, which has another leg plugged in the OVS integration bridge.</div>
<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">
On the other discussion, we generalized the Nova  side VIF plugging to<br>
the Libvirt GenericVIFDriver.<br>
The idea is let neturon tell the VIF plugging configration details to<br>
the GenericDriver, and GerericDriver<br>
takes care of it.<br></blockquote><div><br></div><div>The downside of the generic driver is that so far it's assuming local configuration values are sufficient to correctly determine VIF plugging.</div><div>The generic VIF driver will use the hybrid driver if get_firewall_required is true. And this will happen if the firewall driver is anything different from the NoOp driver.</div>
<div>This was uncovered by a devstack commit (1143f7e). When I previously discussed with the people involved this issue, I was under the impression that the devstack patch introduced the problem. Apparently the Generic VIF driver is not taking at the moments hints from neutron regarding the driver to use, and therefore, from what I gather, makes a decision based on nova conf flags only.</div>
<div>So a quick fix would be to tell the Generic VIF driver to always use hybrid plugging when neutron is enabled (which can be gathered by nova conf flags).</div><div>This will fix the issue for ML2, but will either break or insert an unnecessary extra hop for other plugins.</div>
<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">
<br>
Unfortunatly, HybridDriver is removed before GenericDriver is ready<br>
for security group.<br></blockquote><div><br></div><div>The drivers were marked for deprecation in Havana, and if we thought the GenericDriver was not good for neutron security groups we had enough time to scream.</div><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">
This makes ML2 + OVSDriver + IptablesBasedFirewall combination unfunctional.<br>
We were working on realfix, but we can't make it until Icehouse<br>
release due to design discussions [1].<br></blockquote><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"># Even if neturon side patch isn't merged yet.<br>

<br>
So we are proposing a workaround fix to Nova side.<br>
In this fix, we are adding special version of the GenericVIFDriver<br>
which can work with the combination.<br>
There is two point on this new Driver.<br>
(1) It prevent set conf.filtername. Because we should use<br>
NoopFirewallDriver, we need conf.filtername should be None<br>
when we use it.<br>
(2) use plug_ovs_hybrid and unplug_ovs_hybrid by enforcing<br>
get_require_firewall as True.<br>
<br>
Here is patchs with UT.<br>
<br>
Workaournd fix:<br>
Nova<br>
<a href="https://review.openstack.org/#/c/82904/" target="_blank">https://review.openstack.org/#/c/82904/</a><br>
<br>
Devstack patch for ML2 (Tested with 82904)<br>
<a href="https://review.openstack.org/#/c/82937/" target="_blank">https://review.openstack.org/#/c/82937/</a></blockquote><div><br></div><div>Are there other plugins which need the hybrid driver for sec groups to work? I think so.</div>
<div>And also - the patch does not seem to work according to Jenkins. The failures look genuine to me.</div><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">
<br>
<br>
We have tested the patch 82904 with following test, and this works. <br></blockquote><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">

- Launch VM<br>
- Assign floating ip<br>
- make sure ping to the floating ip is failing from GW<br>
- modify security group rule to allow ping from anywhere<br>
- make sure ping is working<br></blockquote><div><br></div><div>You can actually run your devstack patch with your patch under review in the check queue.</div><div>Check what Aaron did here: <a href="https://review.openstack.org/#/c/78694/11">https://review.openstack.org/#/c/78694/11</a></div>
<div><br></div><div>I wonder if instead of putting this bit of tape, we could just leverage the VIF_TYPE attribute of the port binding extension.</div><div>Most plugins use VIF_TYPE_OVS already. It's a pity the ml2 plugin with the OVS mech driver did not specify VIF_TYPE_OVS_HYBRID.</div>
<div><br></div><div>But, in my opinion if we fix the relevant constants in the plugins which require hybrid plugging, and we slightly change the generic VIF driver logic to make a decision according to the VIF_TYPE binding attribute we should fine, as we'll end up with two small, contained patches, which, IMHO, are not even much ugly.</div>
<div>But again, I'm far from being a subject matter expert when it comes to nova/neutron integration and the ML2 plugin.</div><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">

<br>
[1] Real fix: (defered to Juno)<br>
<br>
Improve vif attributes related with firewalling<br>
<a href="https://review.openstack.org/#/c/21946/" target="_blank">https://review.openstack.org/#/c/21946/</a><br>
<br>
Support binding:vif_security parameter in neutron<br>
<a href="https://review.openstack.org/#/c/44596/" target="_blank">https://review.openstack.org/#/c/44596/</a></blockquote><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">
<br>
<br>
--> I'll put latest update on here<br>
<a href="https://etherpad.openstack.org/p/neturon_security_group_fix_workaround_icehouse" target="_blank">https://etherpad.openstack.org/p/neturon_security_group_fix_workaround_icehouse</a><br>
<br></blockquote><div><br></div><div>Bug report, IRC, mailing list, etherpad, and conf call... why not create a wiki page as well?</div><div>I am joking... to an extent. I actually think updates should just go to the bug report.</div>
<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">
Best<br>
Nachi<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>
</blockquote></div><br></div></div></div>