https://github.com/openshift/cluster-api-provider-openstack/commit/42ae205f8c9046f6b95490d39fb531221bddd274#diff-74426b0daa2349d4dffb9633a1a3ef807c0136fc398d0275213a4734c336f067R290-R313 There isn't a good way for CAPO to lock other async processes or other CAPO threads from taking the same ports. This could potentially lead to a race condition when trying to claim the same port that would result in a failed deployment. Instead CAPO should focus on making sure to create and destroy the resources it needs for a given machine.
ACKed by Kuryr, not a blocker for them.
https://github.com/openshift/cluster-api-provider-openstack/pull/170
2 new pieces of info: 1. CAPO and CAPI is completely sequential 2. The use pattern of looking up a resource by name and using it if found is used throughout the library, and even now in upstream I think that the chance of a race is very low, it might be better off to leave this for now, and engage with upstream to figure this out if we want to change it.
Re-use logic caused the same port to be attached as an interface twice in a customer's system: Duplicate entry 'fa:16:3e:3c:a7:ff/9291d07d-69d3-4f61-a6a3-e105dd5663e0-0' for key 'uniq_virtual_interfaces0address0deleted so Failed to allocate the network(s)
Steps to reproduce: Define a machine spec with 2 subnets that are in the same network.
Issue has been filed upstream as well: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/issues/834
the naming duplication issues have been handled downstream by a separate patch. I will link it when I find it. This is not a blocker for 4.8.
Removing the Triaged keyword because: * the target release value is missing * the QE automation assessment (flag qe_test_coverage) is missing
*** This bug has been marked as a duplicate of bug 1955969 ***