neutron doesn't prevent the network update from external to internal when floatingIPs present
Bug #1806032 reported by
lina He
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
New
|
Low
|
Unassigned |
Bug Description
The floatingIP can be created in an external network, but after updating the external network to internal, the floatingIP is still in that internal network.
The updating from internal network to external should be prevented if there are FloatingIPs existing.
Reproduction:
~$ neutron net-create net1 --router:external true
~$ neutron floatingip-create net1
~$ neutron net-update net1 --router:external fasle
This is based on master and stable/queens.
summary: |
neutron doesn't prevent the network update from external to internal - when floatingIP present + when floatingIPs present |
description: | updated |
description: | updated |
description: | updated |
Changed in neutron: | |
status: | New → Confirmed |
Changed in neutron: | |
importance: | Undecided → Low |
tags: | added: l3-ipam-dhcp |
To post a comment you must log in.
Thank you for your bug report.
I was able to reproduce the problem, here it is with openstack client:
openstack network create --external net1
openstack subnet create subnet1 --network net1 --subnet-range 10.0.4.0/24
openstack floating ip create net1
# succeeds as expected
openstack network create --internal net2
openstack subnet create subnet2 --network net2 --subnet-range 10.0.5.0/24
openstack floating ip create net2
# fails as expected
openstack network set net1 --internal
# succeeds, but it should not
If you had made this comment 5 years ago on the original patch introducing external nets, I'd suggest disabling the updatability of the router:external attribute. However today, after 5 years of having this attribute updatable we clearly cannot make it non-updatable.
While it is technically possible to check the floating ips of a network when the network is being updated, that introduces a dependency (and implicit knowledge) in the wrong direction between networks and floating ips.
Because the first option is impossible and the 2nd is quite undesirable, I'm inclined to set this bug's status to Incomplete and ask about your use case. Could you please write about the reasons you're updating a network's external flag? Can you do that in an alternative way?