Reviewed: https://review.opendev.org/c/openstack/neutron/+/876716
Committed:
https://opendev.org/openstack/neutron/commit/63584957203ec9f5ba165177978213c3909f81f0
Submitter: "Zuul (22348)"
Branch: master
commit 63584957203ec9f5ba165177978213c3909f81f0
Author: elajkat <lajos.kat...@est.tech>
Date: Fri Mar 10 13:29:48 2023 +0100
Delete sg rule which remote is the deleted sg
Based on bug #2008712 if we have a security-group which
is the remote group of a 2nd security-group, the backend
never deletes the rule of the 2nd group which
remote_group_id is the original security-group.
By AFTER_DELETE event for each rule that has the
security_group_id as remote_group_id, we can make the
mech drivers do their work and delete these rules in the
backend.
Change-Id: I207ecf7954b06507e03cb16b502ceb6e2807e0e7
Closes-Bug: #2008712
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2008712
Title:
Security group rule deleted by cascade (because its remote group had
been deleted) is not deleted in the backend
Status in neutron:
Fix Released
Bug description:
devstack 7533276c
neutron aa40aef70f
This reproduction uses the openvswitch ml2 mechanism_driver and
firewall_driver, but I believe this bug affects all mechanism_drivers.
# Choose a port number no other rule uses on the test host.
$ sudo ovs-ofctl dump-flows br-int | egrep 1234
[nothing]
# Create two security groups.
$ openstack security group create sg1
$ openstack security group create sg2
# Create a rule in sg1 that references sg2 (as remote group).
$ openstack security group rule create sg1 --ingress --ethertype IPv4
--dst-port 1234:1234 --protocol tcp --remote-group sg2
# The API returns the new rule.
$ openstack security group rule list sg1
+--------------------------------------+-------------+-----------+-----------+------------+-----------+--------------------------------------+----------------------+
| ID | IP Protocol | Ethertype | IP Range
| Port Range | Direction | Remote Security Group | Remote
Address Group |
+--------------------------------------+-------------+-----------+-----------+------------+-----------+--------------------------------------+----------------------+
| 77db9548-b3ab-46ea-94a5-f00f6a4062da | None | IPv4 | 0.0.0.0/0
| | egress | None | None
|
| 9b569a88-177a-4422-a0f3-6ed039e0217a | tcp | IPv4 | 0.0.0.0/0
| 1234:1234 | ingress | 7df90218-3d52-4156-9630-43563a3d5ba6 | None
|
| f40d258b-4d13-4dc8-a0c4-82ccce9922e0 | None | IPv6 | ::/0
| | egress | None | None
|
+--------------------------------------+-------------+-----------+-----------+------------+-----------+--------------------------------------+----------------------+
# Make sure sg1 is used on the test host.
$ openstack server create --flavor cirros256 --image cirros-0.5.2-x86_64-disk
--availability-zone :devstack0 --nic net-id=private --security-group sg1 vm1
--wait
# See if the rule is implemented in the backend.
$ sudo ovs-ofctl dump-flows br-int | egrep 1234
cookie=0x33704a39bf5031d7, duration=55.263s, table=82, n_packets=0,
n_bytes=0, idle_age=57,
priority=73,ct_state=+est-rel-rpl,tcp,reg5=0x20,tp_dst=1234
actions=conjunction(22,2/2)
cookie=0x33704a39bf5031d7, duration=55.263s, table=82, n_packets=0,
n_bytes=0, idle_age=57, priority=73,ct_state=+new-est,tcp,reg5=0x20,tp_dst=1234
actions=conjunction(23,2/2)
# Delete sg2...
$ openstack security group delete sg2
# ...by cascade also delete the rule in sg1 referencing sg2. At least in the
API.
$ openstack security group rule list sg1
+--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+
| ID | IP Protocol | Ethertype | IP Range
| Port Range | Direction | Remote Security Group | Remote Address Group |
+--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+
| 77db9548-b3ab-46ea-94a5-f00f6a4062da | None | IPv4 | 0.0.0.0/0
| | egress | None | None |
| f40d258b-4d13-4dc8-a0c4-82ccce9922e0 | None | IPv6 | ::/0
| | egress | None | None |
+--------------------------------------+-------------+-----------+-----------+------------+-----------+-----------------------+----------------------+
# But the delete is not propagated to the backend.
$ sudo ovs-ofctl dump-flows br-int | egrep 1234
cookie=0x33704a39bf5031d7, duration=112.917s, table=82, n_packets=0,
n_bytes=0, idle_age=115,
priority=73,ct_state=+est-rel-rpl,tcp,reg5=0x20,tp_dst=1234
actions=conjunction(22,2/2)
cookie=0x33704a39bf5031d7, duration=112.917s, table=82, n_packets=0,
n_bytes=0, idle_age=115,
priority=73,ct_state=+new-est,tcp,reg5=0x20,tp_dst=1234
actions=conjunction(23,2/2)
# Clean up - even the left over backend flows.
$ openstack server delete vm1 --wait
$ sudo ovs-ofctl dump-flows br-int | egrep 1234
[nothing]
$ openstack security group delete sg2
$ openstack security group delete sg1
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2008712/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
