Hi Ilya, My usecase is to run ovsdb-server to serve hardware_vtep ovsdb schema in OVN controller vtep scenario. Container is used to run service on top of linux-based network switch. For now, I just use this patchset internally and it seems sufficient to provide a solution for that. The only problem is we need to re-apply this patch to newer versions unless it is not accepted to upstream… I’m wonder what’s the problem to use this script not only to run ovsdb-server with Open_vSwitch schema with known limitations?
regards, Vladislav Odintsov > On 14 Jul 2023, at 20:20, Ilya Maximets <[email protected]> wrote: > 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
