Sorry, there was a typo. regards, Vladislav Odintsov
> On 17 Jul 2023, at 23:59, Vladislav Odintsov <[email protected]> wrote: > > 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… unless -> until > 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
