| Message ID | 20230607063333.1239159-1-odivlad@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
| Series | [ovs-dev,1/2] utilities: add "--detach" option to ovs-ctl | expand |
| Context | Check | Description |
|---|---|---|
| ovsrobot/apply-robot | success | apply and check: success |
| ovsrobot/github-robot-_Build_and_Test | success | github build: passed |
| ovsrobot/intel-ovs-compilation | success | test: success |
On Wed, Jun 07, 2023 at 09:33:32AM +0300, 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. > > Signed-off-by: Vladislav Odintsov <odivlad@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com>
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. Why not just starting ovsdb/vswitchd processes explicitly in the container? Best regards, Ilya Maximets. > > Signed-off-by: Vladislav Odintsov <odivlad@gmail.com> > --- > utilities/ovs-ctl.in | 5 +++++ > utilities/ovs-lib.in | 8 +++++++- > 2 files changed, 12 insertions(+), 1 deletion(-) > > diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in > index 0b2820c36..72c8881e3 100644 > --- a/utilities/ovs-ctl.in > +++ b/utilities/ovs-ctl.in > @@ -338,6 +338,7 @@ set_defaults () { > DUMP_HUGEPAGES=no > MLOCKALL=yes > SELF_CONFINEMENT=yes > + DETACH=yes > MONITOR=yes > OVS_USER= > OVSDB_SERVER=yes > @@ -442,6 +443,10 @@ Less important options for "start", "restart" and "force-reload-kmod": > --no-full-hostname set short hostname instead of full hostname > --no-record-hostname do not attempt to determine/record system > hostname as part of start command > + --detach=yes|no Run process in background (default: $DETACH). > + If "no", replace current process with "exec". > + Note, that with "no" database settings initialization is not done. > + db-version, system-ids are not set and transient ports are not deleted. > > Debugging options for "start", "restart" and "force-reload-kmod": > --ovsdb-server-wrapper=WRAPPER > diff --git a/utilities/ovs-lib.in b/utilities/ovs-lib.in > index 7812a94ee..9db700e6a 100644 > --- a/utilities/ovs-lib.in > +++ b/utilities/ovs-lib.in > @@ -183,7 +183,13 @@ start_daemon () { > # pidfile and monitoring > install_dir "$rundir" > set "$@" --pidfile="$rundir/$daemon.pid" > - set "$@" --detach > + > + if test X"$DETACH" != Xno; then > + set "$@" --detach > + else > + set exec "$@" > + fi > + > test X"$MONITOR" = Xno || set "$@" --monitor > > # wrapper
Hi Ilya, thanks for the attention on this patchset. > On 13 Jun 2023, at 14:58, Ilya Maximets <i.maximets@ovn.org> 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"]? > Best regards, Ilya Maximets. > >> >> Signed-off-by: Vladislav Odintsov <odivlad@gmail.com> >> --- >> utilities/ovs-ctl.in | 5 +++++ >> utilities/ovs-lib.in | 8 +++++++- >> 2 files changed, 12 insertions(+), 1 deletion(-) >> >> diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in >> index 0b2820c36..72c8881e3 100644 >> --- a/utilities/ovs-ctl.in >> +++ b/utilities/ovs-ctl.in >> @@ -338,6 +338,7 @@ set_defaults () { >> DUMP_HUGEPAGES=no >> MLOCKALL=yes >> SELF_CONFINEMENT=yes >> + DETACH=yes >> MONITOR=yes >> OVS_USER= >> OVSDB_SERVER=yes >> @@ -442,6 +443,10 @@ Less important options for "start", "restart" and "force-reload-kmod": >> --no-full-hostname set short hostname instead of full hostname >> --no-record-hostname do not attempt to determine/record system >> hostname as part of start command >> + --detach=yes|no Run process in background (default: $DETACH). >> + If "no", replace current process with "exec". >> + Note, that with "no" database settings initialization is not done. >> + db-version, system-ids are not set and transient ports are not deleted. >> >> Debugging options for "start", "restart" and "force-reload-kmod": >> --ovsdb-server-wrapper=WRAPPER >> diff --git a/utilities/ovs-lib.in b/utilities/ovs-lib.in >> index 7812a94ee..9db700e6a 100644 >> --- a/utilities/ovs-lib.in >> +++ b/utilities/ovs-lib.in >> @@ -183,7 +183,13 @@ start_daemon () { >> # pidfile and monitoring >> install_dir "$rundir" >> set "$@" --pidfile="$rundir/$daemon.pid" >> - set "$@" --detach >> + >> + if test X"$DETACH" != Xno; then >> + set "$@" --detach >> + else >> + set exec "$@" >> + fi >> + >> test X"$MONITOR" = Xno || set "$@" --monitor >> >> # wrapper > Regards, Vladislav Odintsov
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 <i.maximets@ovn.org> 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.
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 <i.maximets@ovn.org> 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 <i.maximets@ovn.org> 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.
Sorry, there was a typo. regards, Vladislav Odintsov > On 17 Jul 2023, at 23:59, Vladislav Odintsov <odivlad@gmail.com> 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 <i.maximets@ovn.org> 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 <i.maximets@ovn.org> 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.
diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in index 0b2820c36..72c8881e3 100644 --- a/utilities/ovs-ctl.in +++ b/utilities/ovs-ctl.in @@ -338,6 +338,7 @@ set_defaults () { DUMP_HUGEPAGES=no MLOCKALL=yes SELF_CONFINEMENT=yes + DETACH=yes MONITOR=yes OVS_USER= OVSDB_SERVER=yes @@ -442,6 +443,10 @@ Less important options for "start", "restart" and "force-reload-kmod": --no-full-hostname set short hostname instead of full hostname --no-record-hostname do not attempt to determine/record system hostname as part of start command + --detach=yes|no Run process in background (default: $DETACH). + If "no", replace current process with "exec". + Note, that with "no" database settings initialization is not done. + db-version, system-ids are not set and transient ports are not deleted. Debugging options for "start", "restart" and "force-reload-kmod": --ovsdb-server-wrapper=WRAPPER diff --git a/utilities/ovs-lib.in b/utilities/ovs-lib.in index 7812a94ee..9db700e6a 100644 --- a/utilities/ovs-lib.in +++ b/utilities/ovs-lib.in @@ -183,7 +183,13 @@ start_daemon () { # pidfile and monitoring install_dir "$rundir" set "$@" --pidfile="$rundir/$daemon.pid" - set "$@" --detach + + if test X"$DETACH" != Xno; then + set "$@" --detach + else + set exec "$@" + fi + test X"$MONITOR" = Xno || set "$@" --monitor # wrapper
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. Signed-off-by: Vladislav Odintsov <odivlad@gmail.com> --- utilities/ovs-ctl.in | 5 +++++ utilities/ovs-lib.in | 8 +++++++- 2 files changed, 12 insertions(+), 1 deletion(-)