Comment 12 for bug 2043970

I think we should change things so that we don't automatically create a new fabric/vlan if we can't detect which fabric/vlan the interface is connected to. It doesn't really provide any value, since if MAAS sees ten interfaces that might be connected to the same fabric/vlan, MAAS would create ten new fabrics for them. The user then doesn't have any way of knowing what they can trust. Did MAAS detect the right fabric/vlan, or did MAAS not know and created a new one?

MAAS should set the vlan of a newly discovered interface, only if it has an IP, or if there's some other hint as to what the right vlan/fabric would be. If MAAS can't autodetect the right vlan/fabric, it's better to leave it empty, so that the user can see that they need to take action to make it right. MAAS shouldn't lie and make something up. It's better to be honest and admit that the vlan/fabric couldn't be deduced.

Now, this might be a backwards-incompatible change. The model itself actually allows this. But in the documentation and the UI, we say that interface is "Disconnected" if the vlan/fabric is None. However, we also have another way of saying that the interface is disconnected, through the link_connected attribute. This in itself is already confusing, since the two concepts are not tied together. For example, in the UI you have the option to mark an interface as "disconnected". That action touches only the link_connected attribute, but not the vlan/fabric.

So I would argue that this is more of a bug fix. We clarify that the link_connected attribute indicates whether the interface is connected to anything, and if the vlan/fabric is None, it means that MAAS doesn't know which vlan/fabric the interface is connected to.

Both before and after this fix, it would hold that if the interface doesn't have a vlan/fabric, it's not directly usable by MAAS. The only change would be that for unknown interfaces that you want to use, you would have to explicitly a vlan and/or fabric. So it's a slight change in behavior.

The alternative is that we do this change in 4.0 and for 3.X we implement the change to delete empty vlans/fabrics as the last interface get removed.

Although, we might get away if we make the change to not create new fabrics only of hardware-sync, but keep it for commissioning until 4.0. That way, if someone depends on this behavior it would still work. Interfaces that are created through hardware-sync can't be configured anyway, since they get removed when the machine is released. So it's for informational purposes.