Description of problem: After upgrade from OCP4.4 to 4.5 SRV record wasn't cleaned up and potentially may conflict with masters data available via KUBE API Version-Release number of selected component (if applicable): How reproducible: Upgrade from OCP4.4 to 4.5 Steps to Reproduce: 1. Deploy OCP 4.4 which should include SRV record 2. Upgrade to 4.5 3. host -t SRV _etcd-server-ssl._tcp.ocp-edge-cluster-0.qe.lab.redhat.com Actual results: [core@master-0-0 ~]$ host -t SRV _etcd-server-ssl._tcp.ocp-edge-cluster-0.qe.lab.redhat.com _etcd-server-ssl._tcp.ocp-edge-cluster-0.qe.lab.redhat.com has SRV record 0 10 2380 master-0-1.ocp-edge-cluster-0.qe.lab.redhat.com. _etcd-server-ssl._tcp.ocp-edge-cluster-0.qe.lab.redhat.com has SRV record 0 10 2380 master-0-0.ocp-edge-cluster-0.qe.lab.redhat.com. _etcd-server-ssl._tcp.ocp-edge-cluster-0.qe.lab.redhat.com has SRV record 0 10 2380 master-0-2.ocp-edge-cluster-0.qe.lab.redhat.com. Expected results: No SRV record should exist in OCP 4.5 deployment Additional info: [kni@provisionhost-0-0 ~]$ oc version Client Version: 4.4.10 Server Version: 4.4.0-0.nightly-2020-07-04-051327 Kubernetes Version: v1.17.1+a1af596
Setting the target to the current development branch. We can work out whether to do a backport once the issue is identified and resolved in the main branch.
This was never removed on 4.5: https://github.com/openshift/machine-config-operator/blob/4173030d89fbf4a7a0976d1665491a4d9a6e54f1/templates/master/00-master/baremetal/files/baremetal-mdns-config.yaml#L9 It looks like the dependency in baremetal-runtimecfg made it in for 4.5 though, so all we should have to do is backport https://github.com/openshift/machine-config-operator/pull/1556.
For 4.6 this was fixed by https://github.com/openshift/machine-config-operator/pull/1556. Will work on the 4.5 backport in the clone.