Open Stack

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.sadoughi at 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 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/20140603/7bfb8a3d/attachment.html>