Open Stack

As I found out there already is a change made by Xurong Yang that assigns
conntrack zones to ports https://review.openstack.org/#/c/118274/6
If merged, it will make connection tracking easier and will allow to add
functionality for closing connections after updating or deleting security
group rules. I will try to add this functionality basing on the existing
patch and see if it works.
I believe that the change requires attention and discussion as there are
some concerns regarding it. Perhaps somebody could take a look it?

On Fri, Oct 24, 2014 at 9:28 PM, Carl Baldwin <carl at ecbaldwin.net> wrote:

> On Fri, Oct 24, 2014 at 6:17 AM, Salvatore Orlando <sorlando at nicira.com>
> wrote:
> > Assigning a distinct ct zone to each port sounds more scalable. This
> should
> > keep the number of zones per host
>
> Agree that zones could be a good solution to this problem.  +1 to zone
> / port for scalability.  Though it will take a bit more code and
> complexity to kill the right connections than it would with zone /
> rule.
>
> > Once we identify the ports, and therefore the ct zones, then we'd still
> need
> > to find the connections matching the rules which were removed. This does
> not
> > sound like being too difficult, but it can result in searches over long
> > lists - think about an instance hosting a DB or web server.
>
> Are you thinking of listing all connections and then iterating over
> the list with some code to match it to a security group rule being
> removed/updated?  Or, map the security group rule to conntrack filter
> arguments to send to a call to conntrack -D?
>
> This could be problematic.  What if security group rules were
> redundant and an update or removal of a rule should not really affect
> any existing connections?  If all connections were compared instead
> against the set of *remaining* security group rules then this wouldn't
> be a problem.  This sounds non-trivial to me.  I'm probably thinking
> too hard about this.  ;)
>
> > The above two considerations made me suggest the idea of associating ct
> > zones with rules, but it is probably true that this can cause us to go
> > beyond the 2^16 limit.
>
> I agree we'd hit this limit.
>
> Carl
>
> _______________________________________________
> 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/20141030/1c050d5a/attachment-0001.html>