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