metal3-static-ip-set init container fails when there are two interfaces with same MAC and provisioningInterface is not set

[machacekondra]

When metal3-static-ip-set init container is executed on env where there two interface with same MAC address following script: metal3-static-ip-set init container

interface="$(ip -br link show up | grep -i "$mac" | cut -f 1 -d ' ' | cut -f 1 -d '@')"

fails, as it returns both interfaces delimited by new line and so the init container fails, because later such interface name don't exist. Here is example of failed script execution:

+ '[' -z '' ']'
+ '[' -n 78:ac:44:05:35:fc,78:ac:44:06:61:96,78:ac:44:06:62:62 ']'
+ for mac in ${PROVISIONING_MACS//,/ }
+ ip -br link show up
+ grep -qi 78:ac:44:05:35:fc
++ ip -br link show up
++ grep -i 78:ac:44:05:35:fc
++ cut -f 1 -d ' '
+ PROVISIONING_INTERFACE='eno3
br-ex'
+ break
+ '[' -n 'eno3
br-ex' ']'
++ ip -o addr show dev 'eno3
br-ex' scope global
Device "eno3
br-ex" does not exist.
+ [[ -n '' ]]
+ /usr/sbin/ip address flush dev 'eno3
br-ex' scope global
Device "eno3
br-ex" does not exist.

As you can see it tries to find interface:

eno3
br-ex

Workaround is edit provisioning resource provisioning-configuration with following configuration:

spec:
    ...
    provisioningInterface: eno3
    ...

Is there a way to specify such configuration in openshift install config?

[metal3-io-bot]

This issue is currently awaiting triage. If Metal3.io contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance. The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[dtantsur]

Note: metal3-static-ip-set is specific to OpenShift, but I suspect the bug equally applies to upstream containers.

[Rozzii]

/triage needs-information

[dtantsur]

I think you're right that we don't handle a situation where two interfaces have the same MAC. How did you end up in this situation? What the behavior you'd expect? We need to know exactly 1 interface.

P.S. Please avoid OpenShift-isms like metal3-static-ip-set and provisioning-configuration in upstream bugs. I know what you mean because I work on OpenShift, but some people do not. It could be beneficial for you to file a bug in the Red Hat Jira first, so that we can see how much it affects the upstream Metal3.

[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

[metal3-io-bot]

Stale issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle stale.

/close

[metal3-io-bot]

@metal3-io-bot: Closing this issue.

In response to [this](https://github.com/metal3-io/ironic-image/issues/530#issuecomment-2491469128): >Stale issues close after 30d of inactivity. Reopen the issue with `/reopen`. Mark the issue as fresh with `/remove-lifecycle stale`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.