3.2.4 CLI fabric/vlan naming bug

Hello

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

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:

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:

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.

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

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