VLAN name mismatch between web UI and API

[Scott Hussey]

When creating a fabric and updating the default VLAN name via the API, the updated name appears in the web UI correctly. However the API continues to report the name 'untagged' for the default VLAN. Compare the attached screenshot of the UI and the below output from the CLI

sh8121@sh8121-VirtualBox:/var/tmp$ maas localhost vlan read 70 1011
Success.
Machine-readable output follows:
{
    "fabric": "private",
    "id": 5112,
    "secondary_rack": null,
    "vid": 1011,
    "resource_uri": "/MAAS/api/2.0/vlans/5112/",
    "primary_rack": null,
    "mtu": 9000,
    "dhcp_on": false,
    "external_dhcp": null,
    "name": "untagged",
    "fabric_id": 70
}

[Andres Rodriguez (andreserl)]

Hi there,

Can you please provide the version of MAAS you are using?

That said, please attach the output of the following:

 - maas admin vlans read <fabric_id>
 - a UI screenshot of the 'Network' tabs listing.

Thanks!

[Scott Hussey (sh8121)]

I don't have a Network tab, but attached is the Subnets tab which based on the URL I think is equivalent.

sh8121@sh8121-VirtualBox:/var/tmp$ maas localhost version read
Success.
Machine-readable output follows:
{"version": "2.1.3+bzr5573-0ubuntu1", "subversion": "16.04.1", "capabilities": ["networks-management", "static-ipaddresses", "ipv6-deployment-ubuntu", "devices-management", "storage-deployment-ubuntu", "network-deployment-ubuntu", "bridging-interface-ubuntu", "bridging-automatic-ubuntu"]}

sh8121@sh8121-VirtualBox:/var/tmp$ maas localhost vlans read 70
Success.
Machine-readable output follows:
[
    {
        "fabric": "private",
        "resource_uri": "/MAAS/api/2.0/vlans/5112/",
        "dhcp_on": false,
        "mtu": 9000,
        "secondary_rack": null,
        "vid": 1011,
        "id": 5112,
        "external_dhcp": null,
        "fabric_id": 70,
        "primary_rack": null,
        "name": "untagged"
    }
]

[Mike Pontillo (mpontillo)]

I think MAAS needs to improve its handling of fabrics, including the distinction between "untagged" and the default VLAN on the fabric. I think "untagged" doesn't quite describe it, because it could be untagged from the perspective of the port we saw it on the machine where maas-rackd is running, but tagged elsewhere in the network.

I have been thinking about this in the context of MAAS 2.3; we're doing some work to validate MAAS's idea of what a fabric is, so that fabrics can be discovered and modeled correctly out-of-the-box. But this looks like a bug fix that could land for a MAAS 2.2 patch release.

Not sure we want to target it for 2.1, but I've added it since it's known to be affected.

[Andres Rodriguez (andreserl)]

We believe this is no longer an issue in the latest releases of MAAS. Please upgrade to the latest version of MAAS, and If you believe this issue is still present, please re-open this bug report or file a new one.

[Andres Rodriguez (andreserl)]

Hi!

**This is an automated message**

We believe this is may no longer be an issue in the latest MAAS release. Due to the original date of the bug report, we are currently marking it as Invalid. If you believe this bug report still valid against the latest release of MAAS, or if you are still interested in this, please re-open this bug report.

Thanks