Open Stack

Hi all,

In the Neutron weekly meeting today[0], we discussed the ovs-firewall-driver blueprint[1]. Moving forward, OVS features today will give us "80%" of the iptables security groups behavior. Specifically, OVS lacks connection tracking so it won’t have a RELATED feature or stateful rules for non-TCP flows. (OVS connection tracking is currently under development, to be released by 2015[2]). To make the “20%" difference more explicit to the operator and end user, we have proposed feature configuration to provide security group rules API validation that would validate based on connection tracking ability, for example.

Several ideas floated up during the chat today, I wanted to expand the discussion to the mailing list for further debate. Some ideas include:
- marking ovs-firewall-driver as experimental in Juno
- What does it mean to be marked as “experimental”?
- performance improvements under a new OVS firewall driver untested so far (vthapar is working on this)
- incomplete implementation will cause confusion, educational burden
- debugging OVS is new to users compared to debugging old iptables
- waiting for upstream OVS to implement (OpenStack K- or even L- cycle)

In my humble opinion, merging the blueprint for Juno will provide us a viable, more performant security groups implementation than what we have available today.

Amir


[0] http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-06-02-21.01.log.html
[1] https://review.openstack.org/#/c/89712/
[2] http://openvswitch.org/pipermail/dev/2014-May/040567.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140602/2360336a/attachment.html>