MAAS

[2.0rc2] Incorrect DNS records

Bug #1602482 reported by Andres Rodriguez
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
Critical
LaMont Jones
MAAS 2.1.1

Bug Description

br0.maas00 A 192.168.100.254
br0.maas00 A 10.90.90.254
maas00 A 192.168.1.13
maas00 AAAA 2602:306:ce26:fc80:eea8:6bff:fefd:ac70

ubuntu@maas00:/etc/bind/maas$ ip addr sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether ec:a8:6b:fd:ac:70 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.13/24 brd 192.168.1.255 scope global eno1
       valid_lft forever preferred_lft forever
    inet6 2602:306:ce26:fc80:eea8:6bff:fefd:ac70/64 scope global mngtmpaddr dynamic
       valid_lft 2591938sec preferred_lft 604738sec
    inet6 fe80::eea8:6bff:fefd:ac70/64 scope link
       valid_lft forever preferred_lft forever
3: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether c4:d9:87:5b:42:62 brd ff:ff:ff:ff:ff:ff
4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 00:0e:c6:88:b7:9f brd ff:ff:ff:ff:ff:ff
6: lxdbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether ca:8b:ca:28:6a:59 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::c88b:caff:fe28:6a59/64 scope link
       valid_lft forever preferred_lft forever
    inet6 fe80::1/64 scope link
       valid_lft forever preferred_lft forever
11: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:0e:c6:88:b7:9f brd ff:ff:ff:ff:ff:ff
    inet 10.90.90.254/24 brd 10.90.90.255 scope global br0
       valid_lft forever preferred_lft forever
    inet 192.168.100.254/24 brd 192.168.100.255 scope global br0:1
       valid_lft forever preferred_lft forever
    inet6 fe80::20e:c6ff:fe88:b79f/64 scope link
       valid_lft forever preferred_lft forever

Related branches

lp:~lamont/maas/bug-1602482
Blake Rouse (community): Approve
Diff: 102 lines (+21/-18)
2 files modified
src/maasserver/models/staticipaddress.py (+18/-9)
src/maasserver/models/tests/test_staticipaddress.py (+3/-9)
Revision history for this message
Andres Rodriguez (andreserl) wrote :

Right after commissioning, I deployed a machine, and noticed the following in DNS:

enp0s25.node04 A 10.90.90.204 # this IP belongs to the dynamic range.
node04 A 10.90.90.3 # this is the auto assigned IP.

I would have expected that the behavior to be that if the machine is deployed all other DNS records should have been cleared.

Revision history for this message
LaMont Jones (lamont) wrote :

All IPs that are valid (as in have been assigned and not expired) are given interface.fqdn names, unless they are the fqdn choice ("best IP" from get_hostname_ip_mapping -- generally pxeboot interface assigned/static/whatever IP.)

The reported behavior is consistent with the DHCP lease used in commissioning being valid after commissioning finishes (no release at the end of commissioning.)

The quick fix is to use a shorter lease time in maas-dhcp, the more complete fix is to change the commissioning process to actively release the DHCP IP at the end.

Revision history for this message
LaMont Jones (lamont) wrote :

TODO: figure out how to have the commissioning node drop the lease as it shuts down at end of commissioning.

Andres Rodriguez (andreserl)
Changed in maas:
status: New → Triaged
importance: Undecided → High
milestone: none → 2.1.0
Andres Rodriguez (andreserl)
Changed in maas:
importance: High → Critical
Revision history for this message
LaMont Jones (lamont) wrote :

Dropping the lease at shutdown, when the root disk is over the network that you're shutting down, is problematic. It would need to be triggered from systemd's Shutdown target: once triggered, the root disk would be _GONE_. And systemd would, of course, want to log that it had finished that task...

The more-likely-to-work fix is to identify when a DHCPed dynamic address should be ignored in the results for a node.

Andres Rodriguez (andreserl)
Changed in maas:
milestone: 2.1.0 → 2.1.1
MAAS Lander (maas-lander)
Changed in maas:
status: Triaged → Fix Committed
Blake Rouse (blake-rouse)
Changed in maas:
assignee: nobody → LaMont Jones (lamont)
LaMont Jones (lamont)
no longer affects: maas/2.0
Andres Rodriguez (andreserl)
Changed in maas:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.