Open Stack

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> 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.


>
> <-- 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.


> 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.
>
> 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.


>
> 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.


> Best
> Nachi
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140326/80d3c568/attachment.html>