Comment 4 for bug 1874418

In my personal automation I set the public IP on the undercloud to use the IP address of the port on the "public" network[1] to avoid this type of conflict.

We could improve OVB to put the IP's into the output of the stack in [2] and [3], like it's done with the private IP and the floating IP? Make the "Create eth2.conf file" playbook step use a template taking the IP address from the stack output as input?

I'm also not against alterntive 2) in the previous. Using allocation_pool's in OVB, we could split the default /24 networks into a lower and upper range, where the upper range is in OVB's allocation pool and we use the lower range of addresses in the undercloud/overcloud we deploy in OVB. (In the routed networks implementation I opted to use fixed_ips for router addresses[4] in OVB, I exclude those in undercloud/overcloud allocation pools to avoid duplicate addreses.

[1] https://github.com/hjensas/ooo-bp-tripleo-routed-networks-templates-testing/blob/master/ovb/deploy_ovb.sh#L16
[2] https://opendev.org/openstack/openstack-virtual-baremetal/src/branch/master/templates/undercloud.yaml#L54
[3] https://opendev.org/openstack/openstack-virtual-baremetal/src/branch/master/templates/quintupleo.yaml#L190
[4] https://opendev.org/openstack/openstack-virtual-baremetal/src/branch/master/templates/undercloud-networks-routed.yaml#L39-L42