We plan to add `externalEndpoints` to OVNDbCluster CRD. We also plan to define a Service that would provide a single DNS domain name for the whole cluster. The assumption is that MetalLB and dnsmasq will round-robin the backend IP addresses of ovsdb-server pods behind the scenes, which should make it possible to trasparently scale in and out and restart ovsdb-server pods etc. without EDP clients significant impact.

Before we implement the logic in CRDs, it makes sense to first test out the behavior of the clients.

The plan would be:

• Deploy a setup with CP and EDP node that hosts ovn-controller and neutron-ovn-metadata-agent. Make sure replicas>1 for SB OVNDbCluster.
• Create MetalLB and Service resources to load balance between the pods created for SB ovsdb-server.
• Configure EDP node to use the fixed IP (for MetalLB) in agent / ovn-controller configuration.
• Make sure that nothing breaks when a pod is removed from the OVNDbCluster, despite the fact that a new replacement pod receives a different external IP address on internalapi network.
• Check the same for DNS configuration of EDP node SB connectivity.