I think this problem also exist in security group!
At 2014-06-27 11:20:31, stanzgy stan@gmail.com wrote:
I have filed this bug on nova
https://bugs.launchpad.net/nova/+bug/1334938
On Fri, Jun 27, 2014 at 10:19 AM, Yongsheng Gong gong...@unitedstack.com
wrote:
I have reported it on
Yes, once a connection has past the nat tables,
and it's on the kernel connection tracker, it
will keep working even if you remove the nat rule.
Doing that would require manipulating the kernel
connection tracking to kill that connection,
I'm not familiar with that part of the linux network
It¹s kinda ugly, if a user through API/Horizon thinks they¹ve isolated a
host, it should be isolatedŠ
I smell an OSSN here...
On 26/06/2014 17:57, Miguel Angel Ajo Pelayo mangel...@redhat.com
wrote:
Yes, once a connection has past the nat tables,
and it's on the kernel connection tracker, it
I believe this will affect nova-network as well. We probably should use
something like the linux cutter utility to kill any ongoing connections after
we remove the nat rule.
Vish
On Jun 25, 2014, at 8:18 PM, Xurong Yang ido...@gmail.com wrote:
Hi folks,
After we create an SSH connection
I missed that going in, but it appears that clean_conntrack is not done on
disassociate, just during migration. It sounds like we should remove the
explicit call in migrate, and just always call it from remove_floating_ip.
Vish
On Jun 26, 2014, at 1:48 PM, Brian Haley brian.ha...@hp.com wrote:
I have reported it on neutron project
https://bugs.launchpad.net/neutron/+bug/1334926
On Fri, Jun 27, 2014 at 5:07 AM, Vishvananda Ishaya vishvana...@gmail.com
wrote:
I missed that going in, but it appears that clean_conntrack is not done on
disassociate, just during migration. It sounds like
I have filed this bug on nova
https://bugs.launchpad.net/nova/+bug/1334938
On Fri, Jun 27, 2014 at 10:19 AM, Yongsheng Gong gong...@unitedstack.com
wrote:
I have reported it on neutron project
https://bugs.launchpad.net/neutron/+bug/1334926
On Fri, Jun 27, 2014 at 5:07 AM, Vishvananda
