To Reproduce Steps to reproduce the behavior:

1. Deploy an OpenStackProvisionServer with a bogus provisioning "interface" field (pick a NIC name which does not exist on the OCP nodes) or use a real interface that nonetheless has no assigned IPs
2. Notice that the OpenStackProvisionServer nonetheless reaches the "Ready" state, and uses the clusterIP of the OCP node on which its associated pod lands as if it were an IP on the specified provisioning interface

Expected behavior

• The OpenStackProvisionServer resource should not reach the "Ready" state, or, even better, should somehow explicitly report the error that the interface/IP could not be found

Bug impact

• Because the OpenStackProvisionServer falsely succeeds in this context, the provisioning of OSP computes continues and fails later when the OSP computes try to acquire the provisioning image from the wrong IP address.

Known workaround

• Despite the wrong IP being used, this can be made to work if the OCP nodes are otherwise routable from another interface on the OSP computes, but this would be accidental and due to a networking setup oversight on the part of the user (since they intended to use a dedicated provisioning network)