This is in anticipation of https://issues.redhat.com/browse/OSP-20113

Introducing new controllers involves additional complexity on operator side. Especially for controllers that drive agents that themselves have to start subprocesses that assume running in separate namespaces. This is because k8s pod lifecycle is tied to its network namespace.

An alternative for shipping DHCP agent controller could be replacing the remaining use cases it covers in OVN clusters with OVN native implementation. This should allow us to avoid the controller and - with it - all its complexities.

This spike is to collect any remaining use cases for DHCP agent and then decide if it's feasible to go the 'native OVN' route for NextGen.

So far we are aware of a single use case - for bare metal ipv6 provisioning - and we believe that the options needed for it are already supported by OVN core.

This spike involves checking with relevant parties (other teams e.g. HardProv or Compute) to see if we haven't missed anything before we confirm the decision of taking a fully native path for NextGen tenant DHCP.