CAPM3 fail waiting the static interface name specified in the template

[mboukhalfa]

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

E0925 06:16:26.153022       1 controller.go:324] "msg"="Reconciler error" "error"="Failed to create secrets: NIC name not found enp1s0" "Metal3Data"={"name":"test1-workers-template-0","namespace":"metal3"} "cont
roller"="metal3data" "controllerGroup"="infrastructure.cluster.x-k8s.io" "controllerKind"="Metal3Data" "name"="test1-workers-template-0" "namespace"="metal3" "reconcileID"="75cdec08-a060-4a6f-b69e-21b0d80dc072" I0925 06:16:26.154381       1 metal3data_manager.go:163] "msg"="Metadata is part of Metal3DataTemplate" "cluster"="test1" "logger"="controllers.Metal3Data.Metal3Data-controller" "metal3-data"={"Namespace":"metal
3","Name":"test1-workers-template-0"} 

The interface name of the fake nodes was eth1 and that what I see on the inspected BMH:

  hardware:
    cpu:
      arch: x86_64
      clockMegahertz: 2100
      count: 2
      flags:
      - fpu
      - fxsr
      - mmx
      - sse
      - sse2
    firmware:
      bios: {}
    nics:
    - ip: 172.22.0.100
      mac: 00:5c:52:31:3a:9c
      model: 0x1af4 0x0001
      name: eth1
    systemVendor: {}

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 :
metal3-io/utility-images#20

Environment:

• Cluster-api version: v1.8.3
• Cluster-api-provider-metal3 version: v1.8.1
• Environment (metal3-dev-env or other): dev-env + fakeIPA
• Kubernetes version: (use kubectl version):
  Client Version: v1.31.0
  Kustomize Version: v5.4.2
  Server Version: v1.30.0

/kind bug

[Rozzii]

We have noticed it during discussion on metal3-io/utility-images#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".

[Rozzii]

/triage accepted

[metal3-io-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[Rozzii]

/remove-lifecycle stale
This is still a serious issue.