<div dir="ltr">The thread branched, and it's getting long.<div>I'm trying to summarize the discussion for other people to quickly catch up.</div><div><br></div><div>- The bug being targeted is <a href="https://bugs.launchpad.net/neutron/+bug/1297469" style="font-size:13px;font-family:arial,sans-serif" target="_blank">https://bugs.launchpad.net/neutron/+bug/1297469</a></div>
<div>It has also been reported as <a href="https://bugs.launchpad.net/neutron/+bug/1252620" target="_blank">https://bugs.launchpad.net/neutron/+bug/1252620</a> and as <a href="https://bugs.launchpad.net/nova/+bug/1248859" target="_blank">https://bugs.launchpad.net/nova/+bug/1248859</a></div>
<div>The fix for bug 1112912 had a fix for it.</div><div>- The problem is the generic VIF driver does not perform hybrid plugging which is required by Neutron when running with ML2 plugin and OVS mech driver</div><div>- The proposed patches (#21946 and #44596) are however very unlikely to merge in icehouse</div>
<div>- An alternative approach has been proposed (<a href="https://review.openstack.org/#/c/82904/" target="_blank">https://review.openstack.org/#/c/82904/</a>); this will 'specialize' the GenericVIF driver for use with neutron.</div>
<div>It is meant to be a temporary workaround pending permanent solution. It's not adding conf variables, but has probably docImpact.</div><div>If that works for nova core, that works for me as well</div><div>- An idea regarding leveraging VIF_TYPE and fixing the issue has been launched. This will constitute a fix which might be improved in the future, and is still small and targeted. However we still need to look at the issue Nachi's pointing out regarding the fact that a libvirt network filter name should not be added in guest config.</div>
<div><br></div><div><div class="gmail_extra"></div>Salvatore<br><div class="gmail_extra">
<br><div class="gmail_quote">
On 26 March 2014 05:57, Akihiro Motoki <span dir="ltr"><<a href="mailto:motoki@da.jp.nec.com" target="_blank">motoki@da.jp.nec.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 Nachi and the teams,<br>
<div><br>
(2014/03/26 9:57), Salvatore Orlando wrote:<br>
> I hope we can sort this out on the mailing list IRC, without having to schedule emergency meetings.<br>
><br>
> Salvatore<br>
><br>
</div><div>> On 25 March 2014 22:58, Nachi Ueno <<a href="mailto:nachi@ntti3.com" target="_blank">nachi@ntti3.com</a> <mailto:<a href="mailto:nachi@ntti3.com" target="_blank">nachi@ntti3.com</a>>> wrote:<br>
><br>
> 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<br>
><br>
> (I'll put conf call information in IRC)<br>
><br>
><br>
> thanks, but I'd prefer you discuss the matter on IRC.<br>
> 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.<br>
<br>
</div>I can't join the meeting too. It is midnight.<br>
<div><br>
><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>
><br>
> The hybrid solution in Neutron has been around for such a long time that I would hardly call it a "special handling".<br>
> To summarize, the VIF is plugged into a linux bridge, which has another leg plugged in the OVS integration bridge.<br>
><br>
> 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>
><br>
><br>
> The downside of the generic driver is that so far it's assuming local configuration values are sufficient to correctly determine VIF plugging.<br>
> 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.<br>
> 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.<br>
> 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.<br>
> 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).<br>
> This will fix the issue for ML2, but will either break or insert an unnecessary extra hop for other plugins.<br>
<br>
</div>When the generic VIF driver is introduced, OVS VIF driver and the hybrid VIF driver are<br>
considered same as e as both are pluggged into OVS and the hybrid driver is implemeted<br>
as a variation of OVS driver, but the thing is not so simple than the first thought.<br>
The hybrid driver solution lives such a long time and IMO the hybrid VIF driver should<br>
be considered as a different one from OVS VIF driver. I start to think VIF_TYPE_OVS_HYBRID<br>
is a good way as Savaltore mentioned below.<br>
<br>
Another point to be discussed is whether passing vif secuirty attributes work from now on.<br>
Even when neutron security group is enabled, do we need to do some port security mechanism<br>
(anti-spoofing, ....) on nova-compute side (such as libvirt nwfilter) or not?<br>
<div><br>
><br>
><br>
> Unfortunatly, HybridDriver is removed before GenericDriver is ready<br>
> for security group.<br>
><br>
><br>
> 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.<br>
><br>
> 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>
><br>
> # 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>
</div>IIUC, the original intention of get_firewall_required() is to control<br>
whether nwfilter is enabled or not, not to control hybird plugging.<br>
As a plan, get_firewall_required() is changed to look binding:attribute<br>
(binding:capablity:port_filter or binding:vif_security:iptable_required<br>
if I use the concept discussed so far).<br>
What we need is a way to determine hybrid plugging is required or not.<br>
Changing the meaning of get_firewall_required is not a good idea to me.<br>
<div><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><br>
><br>
><br>
> Are there other plugins which need the hybrid driver for sec groups to work? I think so.<br>
> And also - the patch does not seem to work according to Jenkins. The failures look genuine to me.<br>
<br>
</div>There are several plugins whcih need hybrid solution.<br>
I commented the devstack review.<br>
<div><br>
><br>
><br>
><br>
> We have tested the patch 82904 with following test, and this works.<br>
><br>
> - 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>
><br>
><br>
> You can actually run your devstack patch with your patch under review in the check queue.<br>
> Check what Aaron did here: <a href="https://review.openstack.org/#/c/78694/11" target="_blank">https://review.openstack.org/#/c/78694/11</a><br>
><br>
> I wonder if instead of putting this bit of tape, we could just leverage the VIF_TYPE attribute of the port binding extension.<br>
> 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.<br>
><br>
> 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<br>
> binding attribute we should fine, as we'll end up with two small, contained patches, which, IMHO, are not even much ugly.<br>
> But again, I'm far from being a subject matter expert when it comes to nova/neutron integration and the ML2 plugin.<br>
><br>
><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><br>
><br>
><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>
><br>
> Bug report, IRC, mailing list, etherpad, and conf call... why not create a wiki page as well?<br>
> I am joking... to an extent. I actually think updates should just go to the bug report.<br>
<br>
</div>Yeah... etherpad page without any link cannot be search :-(<br>
bug report has a good history.<br>
<div><br>
><br>
> Best<br>
> Nachi<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
</div>> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a> <mailto:<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>
<div><div>><br>
><br>
><br>
><br>
> _______________________________________________<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>
_______________________________________________<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>
</div></div></blockquote></div><br></div></div></div>