[2.0a4] Bridges no longer discovered by the rack controller

Bug #1564657 reported by Andres Rodriguez
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
Critical
Mike Pontillo

Bug Description

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: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 28:d2:44:65:25:55 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.1/24 brd 192.168.10.255 scope global eth0
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 7c:7a:91:40:48:4f brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.72/24 brd 192.168.1.255 scope global dynamic wlan0
       valid_lft 80927sec preferred_lft 80927sec
    inet6 2602:306:ce26:fc80:5038:b1b9:5e83:38a7/64 scope global temporary dynamic
       valid_lft 599325sec preferred_lft 80325sec
    inet6 2602:306:ce26:fc80:7e7a:91ff:fe40:484f/64 scope global mngtmpaddr noprefixroute dynamic
       valid_lft 2591835sec preferred_lft 604635sec
    inet6 fe80::7e7a:91ff:fe40:484f/64 scope link
       valid_lft forever preferred_lft forever
4: virbr2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:01:6e:20 brd ff:ff:ff:ff:ff:ff
    inet 192.168.155.1/24 brd 192.168.155.255 scope global virbr2
       valid_lft forever preferred_lft forever
5: virbr2-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue master virbr2 state DOWN group default qlen 500
    link/ether 52:54:00:01:6e:20 brd ff:ff:ff:ff:ff:ff
6: lxcbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether 5e:4d:01:27:c7:49 brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.1/24 scope global lxcbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::5c4d:1ff:fe27:c749/64 scope link
       valid_lft forever preferred_lft forever
7: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:d3:1a:ac brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
8: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue master virbr0 state DOWN group default qlen 500
    link/ether 52:54:00:d3:1a:ac brd ff:ff:ff:ff:ff:ff
9: virbr1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:c2:29:bb brd ff:ff:ff:ff:ff:ff
    inet 192.168.123.1/24 brd 192.168.123.255 scope global virbr1
       valid_lft forever preferred_lft forever
10: virbr1-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue master virbr1 state DOWN group default qlen 500
    link/ether 52:54:00:c2:29:bb brd ff:ff:ff:ff:ff:ff

The above is my networking setup. Before, MAAS would automatically disover virbr0, vrirbr1 etc, but now it doesn't.

Related branches

Changed in maas:
milestone: none → 2.0.0
importance: Undecided → Critical
Revision history for this message
Blake Rouse (blake-rouse) wrote :

Please provide the output of:

sudo maas-rack support-dump

Also are there any errors in the regiond.log.

Changed in maas:
status: New → Incomplete
Revision history for this message
Andres Rodriguez (andreserl) wrote :
Revision history for this message
Andres Rodriguez (andreserl) wrote :

I see the bridges in the dyump, but not in the controller interfaces.

Revision history for this message
Blake Rouse (blake-rouse) wrote :

Yeah they are being discovered on the rack controller, so the issue is the region is doing something incorrectly to save them into the database.

Revision history for this message
Mike Pontillo (mpontillo) wrote :

We have several bugs in this category, where interface discovery works the first time, but not subsequently after changes.

I'm starting to think we should keep a history of the interface dumps that the region processes, so that we can diff it in the event that we need to for troubleshooting.

Changed in maas:
status: Incomplete → In Progress
assignee: nobody → Mike Pontillo (mpontillo)
Changed in maas:
status: In Progress → Fix Committed
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.

Other bug subscribers

Remote bug watches

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