3.2.4 CLI fabric/vlan naming bug

Development
1

Hello

I might have found a bug in the CLI on maas 3.2.4 (debs).
Fabric definition is from the UI this

image
image2128×1120 117 KB

When querying from the CLI though I cannot get the name of the last VLAN (that maas also reports as the primary VLAN, the first created I assume). It reports as Untagged, though the name in the web interface is there. See here:

image
image2122×1252 114 KB

maas $PROFILE fabrics read | jq “.[] | {name:.name, vlans:.vlans[] | {name:.name, id:.id, vid:.vid}}” --compact-output | grep astro-t
{“name”:“acacia-astro-t”,“vlans”:{“name”:“acacia-astro-t-int”,“id”:5312,“vid”:xxx}}
{“name”:“acacia-astro-t”,“vlans”:{“name”:“acacia-astro-t-srv”,“id”:5313,“vid”:xxx}}
{“name”:“acacia-astro-t”,“vlans”:{“name”:“acacia-astro-t-str”,“id”:5314,“vid”:xxx}}
{“name”:“acacia-astro-t”,“vlans”:{“name”:“untagged”,“id”:5311,“vid”:xxx}}

Even trying to query the vlan directly with CLI results in the same issue where the name is wrongly reported, as untagged:

image
image1056×544 32.3 KB

This is the first time we go in such depth to configure networking with maas, while prior this we were just using puppet after the first boot. Is there anything I am missing here?

We have another 4 fabrics configured in the same way of the one displayed, and in all of them, the “default” vlan (first in numbering) results in the name “untagged” when queried from the CLI, while via the UI the name is correctly displayed.

2

Could anyone please have a look at this and confirm if there is a workaround?
Thanks!

3

Hi @cervigni

This is a very strange behaviour. Can you please tell us a bit more about your setup and maybe even file a bug? Here is a link describing what information might help us.

Maybe you have a caching proxy in front of MAAS that was caching the HTTP API responses? UI takes data from the Websocket API, but data comes from the same source.

Also count it be that you’ve queried the wrong fabric/VLAN? I see on the screenshot VLAN id:5315, but in the JSON output it is id:5311

4

I have found another example in the same cluster of what seems to be the same problem (@cervigni and I are are colleagues). We are now running version 3.2.7, and no there isn’t a proxy in front of MAAS.

09:24 $ maas "$MAAS_USER" vlan read 21 $VID | jq '.name,.id'
"untagged"
5026

while at https://maas/MAAS/r/vlan/5026 Name is storage

This is true for 2 more sets of three VLANs each in the same fabric: The one with the lowest VID suffers this problem, while the other two are fine.

5

Can we have some advice on how to proceed here? Since May we have had a reference to this post next to the workaround in our scripts:

    # create bridge on vlan-interface
    BRIDGE_NAME=$(echo "$FABRICS" | jq -r ".[] | \
        select(.name == \"$DATA_FABRIC_NAME\").vlans | .[] | \
        select(.vid == $VID).name")
    # FIXME https://discourse.maas.io/t/3-2-4-cli-fabric-vlan-naming-bug/6312
    if [ "$BRIDGE_NAME" == 'untagged' ]; then
      BRIDGE_NAME=storage
    fi
    BRIDGE_ID=$(maas "$MAAS_USER" interfaces create-bridge "$SYSTEM_ID" \
        name="$BRIDGE_NAME" parent="$VLAN_IF_ID" mtu=9000 | jq -r .id)