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. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra 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.