Cannot modify the default VLAN for a fabric

Bug #1513373 reported by Dimiter Naydenov
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Invalid
Undecided
Unassigned

Bug Description

I've created a few extra zones, fabrics and VLANs and now I'm trying to change the semantics of those VLANs to match what I've configured on the 2 trunked switches I have:

zone1 (non-default) switch (24-port TP-LINK TL-SG1024DE):

vid=1, name=management, ports=1-24 (untagged)
vid=50, name=public, ports=1,3,5,7,9 (tagged)
vid=100, name=internal, ports=1,3,5,7,9 (tagged)
vid=150, name=admin, ports=1,3,5,7,9 (tagged)
vid=200, name=data, ports=1,2,4,6,8,10 (tagged)
vid=250, name=storage, ports=1,2,4,6,8,10 (tagged)
vid=300, name=cluster, ports=1,2,4,6,8,10 (tagged)

Port 1 is the MAAS uplink and trunks all VLAN traffic going to MAAS.
Port 24 is the downlink to the second switch, also trunked to carry all VLANs.

zone2 switch (8-port D-Link DGS-1100-08):
vid=1, name=management, ports=1-8 (untagged)
vid=50, name=public, ports=1,3,5,7 (tagged)
vid=100, name=internal, ports=1,3,5,7 (tagged)
vid=150, name=admin, ports=1,3,5,7 (tagged)
vid=200, name=data, ports=1,2,4,6,8 (tagged)
vid=250, name=storage, ports=1,2,4,6,8 (tagged)
vid=300, name=cluster, ports=1,2,4,6,8 (tagged)

On each of those switches there are 2 NUCs (DC53427HYE) each with 2 NICs (on-board eth0, used for PXE, and USB2Ethernet adapter as eth1). On every node, eth0 is connected to an odd port of the switch, eth1 - on an even port.

Using 1.9.0~beta1+bzr4417-0ubuntu1~trusty1

Now, I want to model the above setup in MAAS like this:

fabrics:
- id=0, name="management", class_type="pxe", vlans:
  - id=0, name="default", vid=1 (can't change the name - see below).
- id=1, name="control", class_type=null (see below - class_type cannot be unset once set), vlans (all should be tagged):
  - id=1, name="public", vid=50
  - id=2, name="internal", vid=100
  - id=3, name="admin", vid=150
- id=2, name="data", class_type="fast", vlans (none of them should be untagged):
  - id=4, name="data", vid=200
  - id=5, name="storage", vid=250
  - id=6, name="cluster", vid=300
- id=3, name="external", class_type="external", vlans:
  - id=7, name="default", vid=0 (this will contain the external subnet MAAS is on and not managing - 192.168.1.0/24)

Unfortunately MAAS does not allow me to modify the VLAN considered "default" for any of the fabrics:

maas hw-root vlan update 2 4 name="data" vid=200
{"__all__": ["Cannot modify the default VLAN for a fabric."]}
(that VLAN was created with the "data" fabric automatically, so I assume it's the default).

Not being able to modify the default VLAN of a fabric (even just to rename it, but why not change its VID as well) is bad UX IMO.
At least I should be able to change which VLAN is considered a default.

I'm having similar issues with not being to rename the default zone (or change which is the "default"), as well as MAAS not giving me a way to unset a class_type of a fabric via the CLI. I'll file separate bugs for these.

Revision history for this message
Dimiter Naydenov (dimitern) wrote :

Zone renaming is already reported as bug #1381125.

Revision history for this message
Dimiter Naydenov (dimitern) wrote :

Unable to unset class_type for a fabric reported as bug #1513379.

Revision history for this message
Andres Rodriguez (andreserl) wrote :

The default vlan, untagged vlan, is not meant to be modified. This is per design as we are not modeling switch ports. This came as a request from

Marking this as invalid!

Revision history for this message
Andres Rodriguez (andreserl) wrote :

(So this basically means that everything that is on a vlan and is untagged traffic, then it will always be untagged)

Changed in maas:
status: New → Invalid
Revision history for this message
Dimiter Naydenov (dimitern) wrote :

Shouldn't at least provide a way to disable the untagged default VLAN? I'd suggest at least leaving this to Wishlist.

Revision history for this message
Andres Rodriguez (andreserl) wrote :

You cannot disable the untagged VLAN by no means. This is where the PXE traffic will always go through. I'm not marking this as a wishlist, not because it shouldn't be but because this was by design as per discussions in the last sprint.

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.