Open mboukhalfa opened 5 days ago
We have noticed it during discussion on https://github.com/metal3-io/utility-images/pull/20 . As far as I know NIC names e.g. "eth1" are only relevant within the network data file but does not identify the interfaces, for identification the MAC address is used.
From my POV I don't really understand why CAPM3 would need to compare the interface names of the BMH inspection data with the network data file as the interface names are coming from IPA and they might be different when the machine reboots and executes the network configuration via cloud-init.
I suspect that this is a bug and we should remove this "NIC name validation".
/triage accepted
What steps did you take and what happened: While testing applying cluster template with fakeIPA environment the provisioning of bmh did not start though the machine was in the provisoning state and I see the error in the CAPM3
The interface name of the fake nodes was
eth1
and that what I see on the inspected BMH:using the same names used in the cluster template in the fake VMs :
enp1s0, enp2s0
fixed the issue but this might not be the wanted behavior since the nic names are specified by the OS so the cluster template names can be different and should not break the provisioning.What did you expect to happen: CAPM3 should still be able to continue if the nic names are different from the template the only required ID should be the MAC address.
Anything else you would like to add: fakeIPA PR discussion : https://github.com/metal3-io/utility-images/pull/20
Environment:
kubectl version
): Client Version: v1.31.0 Kustomize Version: v5.4.2 Server Version: v1.30.0/kind bug