Open Stack

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 <nachi at ntti3.com <mailto:nachi at 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 at lists.openstack.org <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>