Carl, You are correct in both distinctions. Like I mentioned to Paul, beyond explicit configuration for the cloud operator, documentation and API validation for the end user, is there anything specific you would like to see as a “warning label”?
Amir On Jun 3, 2014, at 9:01 AM, Carl Baldwin <c...@ecbaldwin.net<mailto:c...@ecbaldwin.net>> wrote: How does ovs handle tcp flows? Does it include stateful tracking of tcp -- as your wording below implies -- or does it do stateless inspection of returning tcp packets? It appears it is the latter. This isn't the same as providing a stateful ESTABLISHED feature. Many users may not fully understand the differences. One of the most basic use cases, which is to ping an outside Ip address from inside a nova instance would not work without connection tracking with the default security groups which don't allow ingress except related and established. This may surprise many. Carl 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 _______________________________________________ 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<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
