yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #93287
[Bug 2036423] Re: subnet's gateway ip can be unset while attached to router
Reviewed: https://review.opendev.org/c/openstack/neutron/+/904713
Committed: https://opendev.org/openstack/neutron/commit/f9e40971e94e4fd239fcf7537b0f1200fbd4ee0f
Submitter: "Zuul (22348)"
Branch: master
commit f9e40971e94e4fd239fcf7537b0f1200fbd4ee0f
Author: Rodolfo Alonso Hernandez <ralonsoh@xxxxxxxxxx>
Date: Sun Jan 14 10:20:12 2024 +0000
Forbid the subnet gateway IP deletion if a router interface is attached
When a router interface is created, the corresponding subnet gateway IP
is tested first [1]. If the subnet has no gateway IP, the router
interface cannot be created. This IP will be assigned to this port.
The Neutron API also prevents from modifying the subnet gateway IP
if assigned to a router interface [2]. However the API is not
preventing the subnet gateway IP deletion. This patch is adding
this check.
This patch is being tested in the neutron-tempest-plugin [3].
[1]https://github.com/openstack/neutron/blob/de58c1b99523104a471420ef0468147f13c9e98d/neutron/db/l3_db.py#L902-L904
[2]https://github.com/openstack/neutron/blob/de58c1b99523104a471420ef0468147f13c9e98d/neutron/db/db_base_plugin_v2.py#L715
[3]https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/904710
Closes-Bug: #2036423
Change-Id: I4c7b399a3a052749abdb88fb50be628ee91b63a0
** 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/2036423
Title:
subnet's gateway ip can be unset while attached to router
Status in neutron:
Fix Released
Bug description:
Hello
There's a weird issue with a subnet's gateway ip when it's attached to
a router.
Normally, when you try to attach a subnet to a router, this subnet
needs to have a gateway ip set. Otherwise the attachment will fail.
So we expect the subnet attached to a router to always have a gateway
ip - this is used for creating the router interface after all.
However, when you attach a subnet with a gateway ip to a router and
then attempt to unset this gateway ip... you can do that. There's no
error, there's no connectivity lost, nothing is deleted. The router
interface is still listed under "router show", the port exists, the
connectivity is still working fine, as if nothing happened. But when
you "subnet show", you can see the gateway ip is None.
This will result in error logs whenever the code tries to process
certain things related to the router. Restarting the L3 agent will
result in these errors, for example.
file: neutron/db/dvr_mac_db.py
method: get_subnet_for_dvr()
LOG.error("Could not retrieve gateway port "
"for subnet %s", subnet_info)
file: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py
method: _bind_centralized_snat_port_on_dvr_subnet()
LOG.warning("DVR: Unable to retrieve subnet information "
"for subnet_id %s. The subnet or the gateway "
"may have already been deleted", subnet_uuid)
A user shouldn't be allowed to unset the gateway ip from a subnet
that's already attached to a router. If they can't add a gateway-less
subnet to a router, they shouldn't be allowed to unset it after the
fact as well.
Tested on Stein and quickly checked if the behaviour still exists on
Master.
To reproduce:
- Create a router
openstack router create r1
- Create a network with a subnet with gateway ip set (default behaviour)
openstack network create n1
openstack subnet create --subnet-range <blabla> --network n1 s1
- Add subnet to the router
openstack router add subnet r1 s1
- Unset the gateway ip from the subnet
openstack subnet set --gateway None s1
The gateway ip on the subnet will be listed as None, the router will
still have the interface existing, the port will stil exist, all
connectivity will remain intact, certain actions and agent restarts
will trigger error logs.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2036423/+subscriptions
References