I would like to understand how did we get to this 80%/20% distinction. In other terms, it seems conntrack's RELATED features won't be supported for non-tcp traffic. What about the ESTABLISHED feature? The blueprint specs refers to tcp_flags=ack. Or will that be supported through the source port matching extension which is being promoted?
More comments inline. On 3 June 2014 01:22, Amir Sadoughi <amir.sadou...@rackspace.com> wrote: > 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. > I am stilly generally skeptic of API changes which surface backend details on user-facing APIs. I understand why you are proposing this however, and I think it would be good to get first an assessment of the benefits brought by such a change before making a call on changing API behaviour to reflect security group implementation on the backend. > > 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”? > In this case experimental would be a way to say "not 100% functional". You would not expect a public service provider exposing neutron APIs backed by this driver, but maybe in some private deployments where the missing features are not a concern it could be used. - performance improvements under a new OVS firewall driver untested so far > (vthapar is working on this) > >From the last comment in your post it seems you already have proof of the performance improvement, perhaps you can add those to the "Performance Impact" section on the spec. > - incomplete implementation will cause confusion, educational burden > It's more about technical debt in my opinion, but this is not necessarily the case. > - debugging OVS is new to users compared to debugging old iptables > This won't be a concern as long as we have good documentation to back the implementation. As Neutron is usually sloppy with documentation - then it's a concern. > - 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 > 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