MAAS accepts 0.0.0.0/0 as a subnet, but this breaks DNS update code
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Fix Released
|
Medium
|
Mike Pontillo | ||
2.3 |
Fix Released
|
Medium
|
Mike Pontillo |
Bug Description
MAAS 2.1.4+bzr5591-
It is currently possible to configure 0.0.0.0/0 as a subnet when creating/modifying a subnet in a MAAS fabric.
This creates two issues:
* Any hosts that are deployed after the subnet is created will be assigned to this subnet, even if more specific subnets exist. This could be a UI bug however, in that IPs are being shown that fall under 0.0.0.0/0, but the IPs are assigned to the more specific and correct CIDR also configured in the same fabric. I haven't yet dug into the database to confirm, but suspect this is not necessary.
* Any attempt made by hosts that fall under this new broad subnet will cause the stack trace in the linked paste on each DHCP renewal, and reverse DNS mapping generation will fail: http://
I added additional logging temporarily to zoneconfig.py to confirm that the stack trace occured when processing
Note: I have redacted customer hostnames, IPs and hardware addresses in the output.
Related branches
- MAAS Lander: Needs Fixing
- Mike Pontillo (community): Approve
-
Diff: 330 lines (+83/-35)3 files modifiedsrc/maasserver/forms/subnet.py (+15/-0)
src/maasserver/forms/tests/test_subnet.py (+68/-27)
src/provisioningserver/utils/tests/test_network.py (+0/-8)
- Andres Rodriguez (community): Approve
-
Diff: 304 lines (+83/-27)2 files modifiedsrc/maasserver/forms/subnet.py (+15/-0)
src/maasserver/forms/tests/test_subnet.py (+68/-27)
Changed in maas: | |
milestone: | none → 2.2.0 |
importance: | Undecided → High |
status: | New → Triaged |
importance: | High → Medium |
tags: | added: canonical-bootstack |
Changed in maas: | |
milestone: | 2.2.0 → 2.2.x |
tags: | added: internal |
Changed in maas: | |
milestone: | 2.2.x → 2.3.x |
Changed in maas: | |
milestone: | 2.3.x → 2.4.x |
Changed in maas: | |
status: | Triaged → Incomplete |
Changed in maas: | |
status: | Incomplete → New |
Changed in maas: | |
status: | New → Confirmed |
assignee: | nobody → Mike Pontillo (mpontillo) |
Changed in maas: | |
status: | Confirmed → Fix Committed |
Changed in maas: | |
milestone: | 2.4.x → 2.4.0alpha1 |
status: | Fix Committed → Fix Released |
I ended up digging into the DB further, and found that in our case, all of the IPs which ended up in the 0.0.0.0/0 subnet, were also BMCs defined in the MAAS DB BMC table. I was able to directly reassign them to the more specific subnet by manipulating the subnet ID of the static IP address entry in the database.
Once this was done, the 0.0.0.0/0 subnet showed no allocated IPs, and I was able to remove it. I chose to do this via the database instead of the UI, in case anything more than simply deleting the subnet occurs when removing a subnet in the UI.