The thread branched, and it's getting long. I'm trying to summarize the discussion for other people to quickly catch up.
- The bug being targeted is https://bugs.launchpad.net/neutron/+bug/1297469 It has also been reported as https://bugs.launchpad.net/neutron/+bug/1252620 and as https://bugs.launchpad.net/nova/+bug/1248859 The fix for bug 1112912 had a fix for it. - 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 - The proposed patches (#21946 and #44596) are however very unlikely to merge in icehouse - An alternative approach has been proposed ( https://review.openstack.org/#/c/82904/); this will 'specialize' the GenericVIF driver for use with neutron. It is meant to be a temporary workaround pending permanent solution. It's not adding conf variables, but has probably docImpact. If that works for nova core, that works for me as well - 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. Salvatore On 26 March 2014 05:57, Akihiro Motoki <mot...@da.jp.nec.com> wrote: > Hi Nachi and the teams, > > (2014/03/26 9:57), Salvatore Orlando wrote: > > I hope we can sort this out on the mailing list IRC, without having to > schedule emergency meetings. > > > > Salvatore > > > > On 25 March 2014 22:58, Nachi Ueno <na...@ntti3.com <mailto: > na...@ntti3.com>> wrote: > > > > Hi Nova, Neturon Team > > > > I would like to discuss issue of Neutron + Nova + OVS security group > fix. > > We have a discussion in IRC today, but the issue is complicated so > we will have > > a conf call tomorrow 17:00 UST (10AM PDT). #openstack-neutron > > > > (I'll put conf call information in IRC) > > > > > > thanks, but I'd prefer you discuss the matter on IRC. > > 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. > > I can't join the meeting too. It is midnight. > > > > > <-- Please let me know if this time won't work with you. > > > > Bug Report > > https://bugs.launchpad.net/neutron/+bug/1297469 > > > > Background of this issue: > > ML2 + OVSDriver + IptablesBasedFirewall combination is a default > > plugin setting in the Neutron. > > In this case, we need a special handing in VIF. Because OpenVSwitch > > don't support iptables, we are > > using linuxbride + openvswitch bridge. We are calling this as hybrid > driver. > > > > > > The hybrid solution in Neutron has been around for such a long time that > I would hardly call it a "special handling". > > To summarize, the VIF is plugged into a linux bridge, which has another > leg plugged in the OVS integration bridge. > > > > On the other discussion, we generalized the Nova side VIF plugging > to > > the Libvirt GenericVIFDriver. > > The idea is let neturon tell the VIF plugging configration details to > > the GenericDriver, and GerericDriver > > takes care of it. > > > > > > The downside of the generic driver is that so far it's assuming local > configuration values are sufficient to correctly determine VIF plugging. > > 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. > > 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. > > 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). > > This will fix the issue for ML2, but will either break or insert an > unnecessary extra hop for other plugins. > > When the generic VIF driver is introduced, OVS VIF driver and the hybrid > VIF driver are > considered same as e as both are pluggged into OVS and the hybrid driver > is implemeted > as a variation of OVS driver, but the thing is not so simple than the > first thought. > The hybrid driver solution lives such a long time and IMO the hybrid VIF > driver should > be considered as a different one from OVS VIF driver. I start to think > VIF_TYPE_OVS_HYBRID > is a good way as Savaltore mentioned below. > > Another point to be discussed is whether passing vif secuirty attributes > work from now on. > Even when neutron security group is enabled, do we need to do some port > security mechanism > (anti-spoofing, ....) on nova-compute side (such as libvirt nwfilter) or > not? > > > > > > > Unfortunatly, HybridDriver is removed before GenericDriver is ready > > for security group. > > > > > > 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. > > > > This makes ML2 + OVSDriver + IptablesBasedFirewall combination > unfunctional. > > We were working on realfix, but we can't make it until Icehouse > > release due to design discussions [1]. > > > > # Even if neturon side patch isn't merged yet. > > > > So we are proposing a workaround fix to Nova side. > > In this fix, we are adding special version of the GenericVIFDriver > > which can work with the combination. > > There is two point on this new Driver. > > (1) It prevent set conf.filtername. Because we should use > > NoopFirewallDriver, we need conf.filtername should be None > > when we use it. > > (2) use plug_ovs_hybrid and unplug_ovs_hybrid by enforcing > > get_require_firewall as True. > > IIUC, the original intention of get_firewall_required() is to control > whether nwfilter is enabled or not, not to control hybird plugging. > As a plan, get_firewall_required() is changed to look binding:attribute > (binding:capablity:port_filter or binding:vif_security:iptable_required > if I use the concept discussed so far). > What we need is a way to determine hybrid plugging is required or not. > Changing the meaning of get_firewall_required is not a good idea to me. > > > > > Here is patchs with UT. > > > > Workaournd fix: > > Nova > > https://review.openstack.org/#/c/82904/ > > > > Devstack patch for ML2 (Tested with 82904) > > https://review.openstack.org/#/c/82937/ > > > > > > Are there other plugins which need the hybrid driver for sec groups to > work? I think so. > > And also - the patch does not seem to work according to Jenkins. The > failures look genuine to me. > > There are several plugins whcih need hybrid solution. > I commented the devstack review. > > > > > > > > > We have tested the patch 82904 with following test, and this works. > > > > - Launch VM > > - Assign floating ip > > - make sure ping to the floating ip is failing from GW > > - modify security group rule to allow ping from anywhere > > - make sure ping is working > > > > > > You can actually run your devstack patch with your patch under review in > the check queue. > > Check what Aaron did here: https://review.openstack.org/#/c/78694/11 > > > > I wonder if instead of putting this bit of tape, we could just leverage > the VIF_TYPE attribute of the port binding extension. > > 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. > > > > 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. > > But again, I'm far from being a subject matter expert when it comes to > nova/neutron integration and the ML2 plugin. > > > > > > [1] Real fix: (defered to Juno) > > > > Improve vif attributes related with firewalling > > https://review.openstack.org/#/c/21946/ > > > > Support binding:vif_security parameter in neutron > > https://review.openstack.org/#/c/44596/ > > > > > > > > --> I'll put latest update on here > > > https://etherpad.openstack.org/p/neturon_security_group_fix_workaround_icehouse > > > > > > Bug report, IRC, mailing list, etherpad, and conf call... why not create > a wiki page as well? > > I am joking... to an extent. I actually think updates should just go to > the bug report. > > Yeah... etherpad page without any link cannot be search :-( > bug report has a good history. > > > > > Best > > Nachi > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org <mailto: > OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev