-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove configJob for ovn-controller #195
Remove configJob for ovn-controller #195
Conversation
This allows to get rid of a hostMount shared between the job pod and the main ovsdb-server pod container (to enable communication of vsctl command with the database socket). Getting rid of hostMounts is needed to be able to eventually stop running ovn-controller pods as privileged containers.
This is to prove that this is possible, now that configJob is squashed into the main ovn-controller pod.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: booxter The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test ovn-operator-build-deploy-kuttl |
/hold |
The rationale for this change is:
The drawback for this change is:
The latter could be handled by splitting vswitchd/ovsdb-server from ovn-controller into a separate pod with its own lifecycle. (This is helpful regardless of privileges.) But - then ovn-controller has to talk to vswitchd database somehow, which is - again - AF_UNIX socket and requires a HostMount. So we are back to zero. I don't have an immediate solution to this contradiction. UPD: to clarify, it's not the database socket that can't run via TCP; it's OF connection socket that implies unix: scheme (in ofctl_run). This doesn't change the logic of the argument above, but is important if we consider running db and OF connections through different mechanisms. |
This is invalid. The job was introduced for a reason - to untangle reconfiguration from ovn-controller pod restart. The proper path forward should be to switch the job to connect to OVNController ovsdb-server via AF_INET socket. This is technically possible but requires SSL deployment for the ovsdb-server endpoint. (And then we can switch all its clients to use the certificates - ovn-controller, ovs-vswitchd, and the configJob.) |
Make it part of the startup path for the service. This allows to remove a hostMount dependency, opening a path towards switch to StatefulSet, replacement of all (necessary) volumes with PVC - and removal of privileges.