-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CAPM3 fail waiting the static interface name specified in the template #1998
Comments
We have noticed it during discussion on metal3-io/utility-images#20 . 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 :
metal3-io/utility-images#20
Environment:
kubectl version
):Client Version: v1.31.0
Kustomize Version: v5.4.2
Server Version: v1.30.0
/kind bug
The text was updated successfully, but these errors were encountered: