-
Task
-
Resolution: Done
-
Critical
-
None
-
None
Right now, all 3 processes are bound to the same pod. It means that ovn-controller cannot be updated without bringing ovs down (which means dataplane downtime). OVN and OVS have different lifecycles, and it should be possible to update OVN more frequently and independently of OVS parts.
This task is to split out ovn-controller into a separate pod, achieving no-dataplane-downtime updates for OVN. (Note: some services, e.g. NA or native DHCP / DNS, are implemented by ovn-controller and will be affected by ovn-controller process restart.)
This task will involve proper affinity rules to co-locate vswitchd with ovn-controllers (though if DaemonSets are used, then I believe it is not needed.)
ovn-controller will have to mount a directory with the OF unix socket to talk to vswitchd running in the separate pod.
Marking it as high-priority because this is a regression to OSP 17 where OVS is running on host. (Note that EDP nodes do the same and so are not affected.)
- relates to
-
OSPRH-3019 Run OVNController pod components at minimum privilege escalation level
- Refinement
-
OSPRH-676 [ovn-operator] Remove unnecessary privileges from ovn-controller pods
- Closed
- links to
- mentioned on