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 <c...@ecbaldwin.net> wrote: > On Fri, Oct 24, 2014 at 6:17 AM, Salvatore Orlando <sorla...@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@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
