[2.3, 2.4, UI, b1] Can not change fabric value on subnet page

[Chris Newcomer]

This is reproduced by opening up the subnet page and clicking on "Edit" and changing the fabric to point to another fabric. The result is that the value reverts back to the original setting and doesn't get saved.

Expected result:
To have the new fabric id retained after the settings are saved.

Please let me know if you need more detail. Thanks.

Package versions:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===============================-====================================-============-=================================================
ii maas 2.3.0-6434-gd354690-0ubuntu1~16.04.1 all "Metal as a Service" is a physical cloud and IPAM
ii maas-cli 2.3.0-6434-gd354690-0ubuntu1~16.04.1 all MAAS client and command-line interface
ii maas-common 2.3.0-6434-gd354690-0ubuntu1~16.04.1 all MAAS server common files
ii maas-dhcp 2.3.0-6434-gd354690-0ubuntu1~16.04.1 all MAAS DHCP server
ii maas-dns 2.3.0-6434-gd354690-0ubuntu1~16.04.1 all MAAS DNS server
ii maas-proxy 2.3.0-6434-gd354690-0ubuntu1~16.04.1 all MAAS Caching Proxy
ii maas-rack-controller 2.3.0-6434-gd354690-0ubuntu1~16.04.1 all Rack Controller for MAAS
ii maas-region-api 2.3.0-6434-gd354690-0ubuntu1~16.04.1 all Region controller API service for MAAS
ii maas-region-controller 2.3.0-6434-gd354690-0ubuntu1~16.04.1 all Region Controller for MAAS
ii python3-django-maas 2.3.0-6434-gd354690-0ubuntu1~16.04.1 all MAAS server Django web framework (Python 3)
ii python3-maas-client 2.3.0-6434-gd354690-0ubuntu1~16.04.1 all MAAS python API client (Python 3)
ii python3-maas-provisioningserver 2.3.0-6434-gd354690-0ubuntu1~16.04.1 all MAAS server provisioning libraries (Python 3)

[Andres Rodriguez (andreserl)]

Hi Chris,

Could you please provide the output of the rack controller interfaces? Also, of your subnets?

That said, is the subnet in question configured in any of the rack controller interfaces ? e.g. does a interface X on a region or rack configured with an IP of that subnet, which is in Y fabric?

[Chris Newcomer (cnewcomer)]

Andres,

My configuration is simple. Two interfaces, one public 192.168.1.0/24 and one private 192.168.10.0/23. Region and Rack controller on the same node, no other rack controllers.

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: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:40:d1:c8 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.2/23 brd 192.168.11.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe40:d1c8/64 scope link
       valid_lft forever preferred_lft forever
3: ens9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:bf:f3:32 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.24/24 brd 192.168.1.255 scope global ens9
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:febf:f332/64 scope link
       valid_lft forever preferred_lft forever

The subnet I'm trying to move to a different fabric is ens9. The interface does have an IP assigned via my external dhcp provider. Both fabrics I'm trying to move are untagged. The subnet output is attached.

[Andres Rodriguez (andreserl)]

Great! Thanks Chris, one more quick question, no tracebacks in the logs?

[Andres Rodriguez (andreserl)]

Actually, nevermind, I just confirmed this bug and there was no error log at all.

This would seem like a fallout of the UI.

How I reproduced:

1. had fabric-5 w/ subnet 192.168.122.2
2. created fabric 'local' and tried to update the subnet to change it to the different fabric.
3. Saving continued, but it didn't update anything.

I've confirmed this with 2.4

[Mike Pontillo (mpontillo)]

This is a somewhat strange bug at first glance, because in the MAAS data model, subnets are not directly associated with fabrics. They are associated with VLANs, and VLANs are on a specific fabric. In other words, you cannot actually change the fabric of a subnet. You can only change the VLAN of a subnet, and the new fabric is implied.

That said, I wonder if changing the fabric doesn't automatically update the VLAN drop-down. (When you change the fabric, the VLAN drop-down should change its filter to show the available VLANs on the new fabric.)

Can you test to see if clicking on the VLAN drop-down and choosing the correct VLAN (even if it's already selected) is a workaround? I'm guessing that when you update the fabric, if there is only one VLAN in the new fabric, it is not automatically selected in the VLAN drop-down (the old VLAN, which would no longer be available, but may have the same 'untagged' label, might remain selected).

[Andres Rodriguez (andreserl)]

I cna confirm this is an issue on the UI only. Updating over the API works just fine.

[Mike Pontillo (mpontillo)]

I've got a fix proposed for this, but the full fix may also require a fix for bug #1759946, otherwise moving a subnet will leave each interface with an IP address on the subnet confused about which VLAN it belongs to.