interface with a warning is not configured properly

[Marian Gasparovic]

We have one machine which shows with yellow triangle and "Link connected to a slow interface" message on one NIC.

When machine is deployed, this interface fails to be configured resulting in missing VLANs.
Works fine in MAAS 2.9

2.9
ubuntu@pangoro:~$ ip -c -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 10.246.64.202/21 fe80::eeb1:d7ff:fe7f:ffb4/64
eth1 UP fe80::eeb1:d7ff:fe7f:ffb5/64
eth2 UP
eth3 UP
bond0 UP fe80::eeb1:d7ff:fe7f:ffb6/64
bond0.2735@bond0 UP 192.168.35.70/26 fe80::eeb1:d7ff:fe7f:ffb6/64
bond0.2736@bond0 UP 192.168.36.70/26 fe80::eeb1:d7ff:fe7f:ffb6/64
eth1.2696@eth1 UP 192.168.33.164/25 fe80::eeb1:d7ff:fe7f:ffb5/64
eth1.2678@eth1 UP 10.244.8.133/24 fe80::eeb1:d7ff:fe7f:ffb5/64

3.0rc2
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP 10.246.64.208/21 fe80::eeb1:d7ff:fe7f:ffb4/64
eno2 DOWN
eth2 UP
eth3 UP
bond0 UP fe80::eeb1:d7ff:fe7f:ffb6/64
bond0.2735@bond0 UP 192.168.35.70/26 fe80::eeb1:d7ff:fe7f:ffb6/64
bond0.2736@bond0 UP 192.168.36.70/26 fe80::eeb1:d7ff:fe7f:ffb6/64

Machine named pangoro in https://solutions.qa.canonical.com/testruns/testRun/cfeb78fe-fa07-415b-922d-01b270f57996

[Björn Tillenius (bjornt)]

I did a bit of digging here. One of the issues is that eno2 on pangoro is considered disconnected. If you don't configure the interface and log in to pangoro, you can see with 'ip link' that eno2 doesn't have a CARRIER.

If you manually configure the interface, it does come up after a while. I tried to ping a known host, but the first 9 pings were lost. Only after that, the interface started receiving traffic.

That's most likely a cabling or switch configuration issue. I would suggest that you look into that, since I would think that would cause problems in the Openstack deployment itself.

The reason it works in 2.9, is that we don't properly detect that there's no link. I tried commissioning a machine with a NIC that didn't have a cable attached, and in 2.9 it was still reported as "link_connected" and "enabled". While in 3.0, it's properly reported as not connected, and not enable.

I don't think it makes sense to change 3.0 to work like in 2.9 in that regard, since that's clearly a bug that got fixed.

We might consider to mark the interface as enabled if you explicitly set the vlan of the interface, like you do. On the other hand, I think you should be aware of the fact that you're configuring a device that isn't connected. So we might also want to error out, and require the user to explicitly enable the interface first.

SolQA, what do you think?

[Björn Tillenius (bjornt)]

Although, I wonder if we shouldn't keep all interfaces 'enabled' after commissioning. Even if it's disconnected, you might still want to have it configured, so that the name gets set.

[Marian Gasparovic (marosg)]

Hello Björn. We like comment #2, it is a good idea to allow configuration is such case. Maybe just throw a warning about configuring disconnected interface, but allow to do it.

[Björn Tillenius (bjornt)]

Yeah, I've put up an MP for keeping the interface enabled.

I did fix things that that link_connected is now properly set to False. So in the UI, you now see a message saying that the interface is not connected, rather than it being connected with a slow speed.

I did confirm that the interface gets included in the netplan, and setting the vlan via the API works without any problems (as well as creating and configuring a vlan interface on top of it).