On 6/13/23 14:33, Vladislav Odintsov wrote: > Hi Ilya, > > thanks for the attention on this patchset. > >> On 13 Jun 2023, at 14:58, Ilya Maximets <[email protected]> wrote: >> >> On 6/7/23 08:33, Vladislav Odintsov wrote: >>> Default is yes (current behavior). This means that after start process >>> will be run in background. When "no" is given, process is run in >>> foreground with `exec` call, which replaces current process (ovs-ctl) with >>> wanted ovs process (ovsdb-server or ovs-vswitchd). >>> >>> This option is useful when running ovs-ctl inside docker container to make >>> ovs* process to be a pid 1. >>> >>> Note, that with `--detach=no` database settings initialization is not done. >>> db-version, system-ids are not set and transient ports are not deleted. >> >> Hi, Vladislav. >> >> It seems like this option makes too many compromises and not really possible >> to use with many of the other options. The main use case for ovs-ctl from >> the beginning was to automate managing of two processes (ovsdb-server and >> ovs-vswitchd) at the same time. Later the ability to manage only one of them >> was added. With this new option it will also be not possible to run both. > > If we’re talking about docker container, where it’s not common practive to > run more than one process inside of container, so I think it should not be a > surprise that two processes can’t be run with using this option. > Maybe it should have been documented in more details instead? To remove > improper understanding of this option? > >> >> Why not just starting ovsdb/vswitchd processes explicitly in the container? >> > > I do really like how ovs-ctl script parametrises OVS daemons to run in > systemd.service unit files and prepares/maintains db files (including schema > update). > Recently I was looking for official solutions how to run OVS daemons inside > docker and haven’t found anything. > I guess it’s a problem for the OVS project since it’s definitely used by many > people to run inside containers and how to create and spawn them is outside > of OVS project and everybody decides each time in its own way... > Using ovs-ctl script helps maintain same argument set for both: systemd and > in-container process. > > Moreover, as a user, I’d be very happy if I can just get official Dockerfile > for popular platforms to run OVS daemons. Just build and run. > > What do you think? > > Maybe I’m wrong :) > How do you maintain OVS daemons inside containers? Just write CMD ["sh", > "-c", "ovsdb-server $OVSDB_SERVER_OPTIONS"]?
There is some code to build and run OVS in a container in utilities/docker. Some documentation is available here: https://docs.openvswitch.org/en/latest/intro/install/general/#starting-ovs-in-container I never actually used that, but just tried and at least it seems to be able to build an image still. Maybe enhancing this workflow should be a way forward, if there are some missing bits. The problem with containers I see is that it's generally not a simple task to manage databases on shared volumes or managing dependencies between containers (ovs-vswitchd requires ovsdb-server). Container runtimes typically lack dependency management. The ovs-vswitchd also needs to be privileged and run with a host network. So, there are not many benefits of containerizing it. Some of the large users like ovn-kubernetes in OpenShift actually dropped their attempts to manage containerized OVS and are just running it as a systemd service these days. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
