[ovs-dev] [ovn] ovn-controller high memory consumption with sbrec_server_has_##table##_table - enabled codepath
Hi, we’ve noticed there is a huge ovn-controller memory consumption introduced with [0] comparing to version without its changes in ovn-controller.c part (just OVS submodule bump without ovn-controller changes doesn’t trigger such behaviour). On an empty host connected to working cluster ovn-controller normally consumes ~175 MiB RSS, and the same host updated to a version with commit [0] consumes 3.3 GiB RSS. The start time and CPU consumption during process start of an affected version is higher that for the normal version. Before upgrade (normal functioning): #ovn-appctl -t ovn-controller memory/show ;ps-mem -p $(pidof ovn-controller)| grep ovn idl-cells-OVN_Southbound:343855 idl-cells-Open_vSwitch:14131 ofctrl_desired_flow_usage-KB:76 ofctrl_installed_flow_usage-KB:60 ofctrl_sb_flow_ref_usage-KB:18 174.2 MiB + 327.5 KiB = 174.5 MiB ovn-controller After upgrade to an affected version I’ve checked memory report while ovn-controller was starting and at some time there was a bigger amount of OVN_Southbound cells comparing to "after start" time: during start: # ovn-appctl -t ovn-controller memory/show ;ps-mem -p $(pidof ovn-controller)| grep ovn idl-cells-OVN_Southbound:11388742 idl-cells-Open_vSwitch:14131 idl-outstanding-txns-Open_vSwitch:1 3.3 GiB + 327.0 KiB = 3.3 GiB ovn-controller after start: # ovn-appctl -t ovn-controller memory/show ;ps-mem -p $(pidof ovn-controller)| grep ovn idl-cells-OVN_Southbound:343896 idl-cells-Open_vSwitch:14131 idl-outstanding-txns-Open_vSwitch:1 3.3 GiB + 327.0 KiB = 3.3 GiB ovn-controller cells during start: 11388742 cells after start: 343896 I guess it could be connected with this problem. Can anyone look at this and comment please? 0: https://github.com/ovn-org/ovn/commit/1b0dbde940706e5de6e60221be78a278361fa76d Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn] controller: disable OpenFlow inactivity probing
Hi Mark, thanks for taking time to look on this! Your point with a hung OVS is really an interesting case. From one hand it’s a possible situation, and from another I guess it’s much higher probability for OVS to be busy by some other work rather than to hang in a loop. In my installation the first happening sometimes (OVS business by real work). The reasons can be different but I can’t say that it’s better to drop OF connection in such a moment (possibly triggering ha chassis-redirect ports failover). At the same time if we’re talking about L3GW node, which has a gateway chassis redirect port, the hung OVS should be detected by other nodes with BFD probes (if it’s a ha chassis-redirect port). And if it’s a normal hypervisor (with just a vif ports), so what can we do with it? I guess if we drop OF connection, it won’t make any positive changes. Maybe just release memory needed for handling this connection and not allocate buffers…? Unfortunately I can’t evaluate this. Moreover, the OVN default is a disabled probing. What can be a possible recommended values to set probes if to leave it as is? How should users find out that they have to configure this? Currently in docs there is only information that this option configures probe interval. But it’s not obvious when to configure it and which value to set. I hope this makes sense. Also, which Han’s patch to OVS you’re talking about? I looked through open OVS patches and haven’t seen any. Please point me out. regards, Vladislav Odintsov > On 9 Jun 2023, at 18:28, Mark Michelson wrote: > > Hi, > > Thanks for linking the email thread, since I had the exact same concern that > Numan did about detecting if ovs-vswitchd goes down. It sounds like because > of the nature of unix sockets, this disconnection is still detected by OVN > and failover can occur as expected. > > But what about if ovs-vswitchd is still running but in a "compromised" state. > For instance, what if a coding error in ovs-vswitchd results in it running an > infinite loop? In such a case, the unix connection would still be alive, but > OVN would not be able to communicate with the ovs-vswitchd process. > > Does this situation eventually lead to OVN disconnecting anyway after it > fills up the unix socket's buffer? If so, how long does that take? Or does it > lead to OVN slowly growing in memory usage while it waits forever to be able > to write to the socket? > > I think removing the hard-coded 5 second probe intervals from pinctrl.c and > features.c is a good idea. But I think we should leave the configurable probe > interval used by ofctrl.c for the case I described before. Since Han's patch > to OVS should disable probe intervals from the OVS side by default, we would > not trigger bad behavior simply because OVN has a lot of work to do during a > recompute. What do you think? >> On 6/8/23 10:15, Vladislav Odintsov wrote: >> OpenFlow connection is established over unix socket, which is a reliable >> connection and doesn't require additional probing. >> With this patch openflow probing in ovn-controller -> ovs-vswitchd >> direction is disabled for all three connections: >> - OF flows management connection, >> - OF features negotiation connection, >> - pinctrl connection. >> ovn-controller external_ids:ovn-openflow-probe-interval is removed as >> non-needed anymore. >> Disablement for ovs-vswitchd -> ovn-controller OF inacivity probing will >> be done in the next patch. >> Reported-at: >> https://mail.openvswitch.org/pipermail/ovs-dev/2023-May/404625.html >> Signed-off-by: Vladislav Odintsov >> --- >> NEWS| 5 + >> controller/ofctrl.c | 14 ++ >> controller/ofctrl.h | 4 +--- >> controller/ovn-controller.8.xml | 14 -- >> controller/ovn-controller.c | 21 + >> controller/pinctrl.c| 2 +- >> lib/features.c | 7 ++- >> 7 files changed, 12 insertions(+), 55 deletions(-) >> diff --git a/NEWS b/NEWS >> index 645acea1f..bd63b187b 100644 >> --- a/NEWS >> +++ b/NEWS >> @@ -1,5 +1,10 @@ >> Post v23.06.0 >> - >> + - Disable OpenFlow inactivity probing between ovn-controller and OVS. >> +OF connection is established over unix socket, which is a reliable >> +connection method and doesn't require additional probing. >> +external_ids:ovn-openflow-probe-interval configuration option for >> +ovn-controller is no longer matter. >>OVN v23.06.0 - 01 Jun 2023 >> -- >> diff --git a/controller/ofctrl.c b/co
Re: [ovs-dev] [PATCH ovn v2] controller, northd: pass arp/nd from HW VTEP to lrouter pipeline
Thanks Dumitru! > On 14 Jun 2023, at 16:37, Dumitru Ceara wrote: > > On 5/30/23 17:03, Vladislav Odintsov wrote: >> This patch is intended to make next two changes: >> >> 1. Support create/update of MAC_Binding for GARP/ND from HW VTEP. >> >> Prior to this patch MAC_Binding records were created only when LRP issued >> ARP request/Neighbor solicitation. If IP to MAC in network attached via >> vtep lport was changed the old MAC_Binding prevented normal >> communication. Now router port (chassisredirect) in logical switch with >> vtep lport catches GARP or Neighbor Solicitation and updates MAC_Binding. >> >> New flow with max priority was added in ls_in_arp_nd_resp and additional >> OF rule in table 37 (OFTABLE_REMOTE_OUTPUT) to process multicast packets >> received from RAMP_SWITCH. >> >> 2. Answer to ARP/ND on requests coming from HW VTEP in lrouter pipeline. >> >> This is needed to reduce duplicated arp-responses, which were generated >> by OVN arp-responder flows in node, where chassisredirect port located >> with responses coming directly from VM interfaces. >> >> As a result of this change, now vifs located on same chassis, where >> chassisredirect ports are located receive ARP/ND mcast packets, which >> previously were suppressed by arp-responder on the node. >> >> Tests and documentation were updated to conform to new behaviour. >> >> Signed-off-by: Vladislav Odintsov >> --- > > Thanks, Vladislav, for the new support! I applied this to the main > branch and it will be available in the next release. > > Regards, > Dumitru > > ___ > dev mailing list > d...@openvswitch.org <mailto:d...@openvswitch.org> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 1/2] utilities: add "--detach" option to ovs-ctl
Hi Ilya,
thanks for the attention on this patchset.
> On 13 Jun 2023, at 14:58, Ilya Maximets 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
>> ---
>> 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|noRun 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
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [ovn] ha-chassis-group false positive failover
Hi, I’ve sent the first part (OF probing disable) - https://patchwork.ozlabs.org/project/ovn/patch/20230608141555.1339905-1-odiv...@gmail.com/ Regarding configuration on the OVS side, I see it’s not working like I wrote before, I’ve deceived myself :) I’ve written some code in ovn-controller, which creates controller for integration bridge with inactivity probe, it successfully creates record, but it hits OVS controller paths restrictions: 2023-06-07T21:08:01.552Z|00338|bridge|ERR|bridge br-int: Not adding Unix domain socket controller "punix:/var/run/ovn/br-int.mgmt" due to possibility of overwriting local files. Instead, specify path in permitted format "punix:/var/run/openvswitch/br-int.*" or connect to "unix:/var/run/openvswitch/br-int.mgmt" (which is always available without special configuration). And in my manual tests I created controller in a directory /var/run, which in centos made a workaround how to add socket on the same path, but allowed to bypass ovs checks (/var/run/openvswitch/… vs /run/openvswitch/…), because of symlink /var/run/ -> /run. So, if you guys have any suggestion how to disable OF probes on a standard OVS controller socket (br-int.mgmt), please give an advice. Alternatively I’ve been thinking about creation another socket with another path for ovs-vswitchd<->ovn-controller OF communication. But I’m concerned about paths consistency across different distributions… Thoughts? > On 6 Jun 2023, at 13:28, Vladislav Odintsov wrote: > > Hi Han, > > thanks for your inputs! > Please see comments inline. > >> On 5 Jun 2023, at 21:01, Han Zhou wrote: >> >> On Mon, Jun 5, 2023 at 8:58 AM Vladislav Odintsov > <mailto:odiv...@gmail.com>> wrote: >>> >>> Hi Dumitru, Ilya, Han, >>> >>> do you guys have any comments here? >>> I’m gonna start working on this change in near future... >>> >>> Thank you. >>> >>> On 17 May 2023, at 18:34, Numan Siddique >> <mailto:num...@ovn.org>> wrote: >>> >>> On Wed, May 17, 2023 at 4:44 AM Vladislav Odintsov >> <mailto:odiv...@gmail.com>> >> wrote: >>> >>> >>> >>> >>> On 16 May 2023, at 23:54, Numan Siddique >> <mailto:num...@ovn.org>> wrote: >>> >>> Hi Vladislav, >>> >>> Sorry for the late reply. >>> >>> PSB for few comments. >>> >>> >>> >>> Thanks for your reply! >>> My answers are inline. >>> >>> >>> >>> >>> On Tue, May 16, 2023 at 3:42 PM Vladislav Odintsov >> <mailto:odiv...@gmail.com> >> <mailto:odiv...@gmail.com>> wrote: >>> >>> >>> Hi Numan, Dumitru, Ilya, >>> >>> I guess I’ve managed to deal with some of these problems and have some >> conclusions. >>> Please see inline. >>> >>> On 14 Apr 2023, at 16:26, Vladislav Odintsov >> <mailto:odiv...@gmail.com>> wrote: >>> >>> And as a follow-up, I see sometimes next error message in ovn-controller >> log, though there is a configured much higher limit in seconds for >> inactivity probe value for the chassis: >>> >>> >>> ovn-controller establishes 3 openflow connections to local ovs-vswitchd >> for next purposes: >>> 1. openflow rules management (openflow probe interval is configured >> through ovn-openflow-probe-interval external_ids setting [1]; default — >> disabled [2]); >>> 2. openflow features collection (hardcoded probe interval 5s [3]); >>> 3. pinctrl thread (hardcoded probe interval 5s [4]). >>> >>> ovs|04426|rconn|ERR|unix:/run/openvswitch/br-int.mgmt: no response to >> inactivity probe after 8 seconds, disconnecting >>> >>> ovs|26560|rconn|ERR|unix:/run/openvswitch/br-int.mgmt: no response to >> inactivity probe after 10 seconds, disconnecting >>> >>> >>> These messages most likely related to the connection for features >> collection or pinctrl thread. So ovn-openflow-probe-interval has no matter >> here. >>> >>> >>> server with first log message: >>> # ovs-vsctl get open . external_ids:ovn-openflow-probe-interval >>> "30" >>> >>> server with second log message: >>> # ovs-vsctl get open . external_ids:ovn-openflow-probe-interval >>> "60" >>> >>> >>> >>> On 30 Mar 2023, at 23:19, Vladislav Odintsov >> <mailto:odiv...@gmail.com>> wrote: >>> >>&
[ovs-dev] [PATCH ovn] controller: disable OpenFlow inactivity probing
OpenFlow connection is established over unix socket, which is a reliable
connection and doesn't require additional probing.
With this patch openflow probing in ovn-controller -> ovs-vswitchd
direction is disabled for all three connections:
- OF flows management connection,
- OF features negotiation connection,
- pinctrl connection.
ovn-controller external_ids:ovn-openflow-probe-interval is removed as
non-needed anymore.
Disablement for ovs-vswitchd -> ovn-controller OF inacivity probing will
be done in the next patch.
Reported-at: https://mail.openvswitch.org/pipermail/ovs-dev/2023-May/404625.html
Signed-off-by: Vladislav Odintsov
---
NEWS| 5 +
controller/ofctrl.c | 14 ++
controller/ofctrl.h | 4 +---
controller/ovn-controller.8.xml | 14 --
controller/ovn-controller.c | 21 +
controller/pinctrl.c| 2 +-
lib/features.c | 7 ++-
7 files changed, 12 insertions(+), 55 deletions(-)
diff --git a/NEWS b/NEWS
index 645acea1f..bd63b187b 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,10 @@
Post v23.06.0
-
+ - Disable OpenFlow inactivity probing between ovn-controller and OVS.
+OF connection is established over unix socket, which is a reliable
+connection method and doesn't require additional probing.
+external_ids:ovn-openflow-probe-interval configuration option for
+ovn-controller is no longer matter.
OVN v23.06.0 - 01 Jun 2023
--
diff --git a/controller/ofctrl.c b/controller/ofctrl.c
index 64a444ff6..788634494 100644
--- a/controller/ofctrl.c
+++ b/controller/ofctrl.c
@@ -415,11 +415,9 @@ static void ofctrl_recv(const struct ofp_header *, enum
ofptype);
void
ofctrl_init(struct ovn_extend_table *group_table,
-struct ovn_extend_table *meter_table,
-int inactivity_probe_interval)
+struct ovn_extend_table *meter_table)
{
-swconn = rconn_create(inactivity_probe_interval, 0,
- DSCP_DEFAULT, 1 << OFP15_VERSION);
+swconn = rconn_create(0, 0, DSCP_DEFAULT, 1 << OFP15_VERSION);
tx_counter = rconn_packet_counter_create();
hmap_init(&installed_lflows);
hmap_init(&installed_pflows);
@@ -2986,14 +2984,6 @@ ofctrl_is_connected(void)
return rconn_is_connected(swconn);
}
-void
-ofctrl_set_probe_interval(int probe_interval)
-{
-if (swconn) {
-rconn_set_probe_interval(swconn, probe_interval);
-}
-}
-
void
ofctrl_get_memory_usage(struct simap *usage)
{
diff --git a/controller/ofctrl.h b/controller/ofctrl.h
index 105f9370b..46bfccd85 100644
--- a/controller/ofctrl.h
+++ b/controller/ofctrl.h
@@ -49,8 +49,7 @@ struct ovn_desired_flow_table {
/* Interface for OVN main loop. */
void ofctrl_init(struct ovn_extend_table *group_table,
- struct ovn_extend_table *meter_table,
- int inactivity_probe_interval);
+ struct ovn_extend_table *meter_table);
bool ofctrl_run(const struct ovsrec_bridge *br_int,
const struct ovsrec_open_vswitch_table *,
struct shash *pending_ct_zones);
@@ -142,7 +141,6 @@ void ofctrl_check_and_add_flow_metered(struct
ovn_desired_flow_table *,
bool ofctrl_is_connected(void);
-void ofctrl_set_probe_interval(int probe_interval);
void ofctrl_get_memory_usage(struct simap *usage);
#endif /* controller/ofctrl.h */
diff --git a/controller/ovn-controller.8.xml b/controller/ovn-controller.8.xml
index f61f43008..52eb137d3 100644
--- a/controller/ovn-controller.8.xml
+++ b/controller/ovn-controller.8.xml
@@ -147,20 +147,6 @@
- external_ids:ovn-openflow-probe-interval
-
-
- The inactivity probe interval of the OpenFlow connection to the
- OpenvSwitch integration bridge, in seconds.
- If the value is zero, it disables the connection keepalive feature.
-
-
-
- If the value is nonzero, then it will be forced to a value of
- at least 5s.
-
-
-
external_ids:ovn-encap-type
diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
index 3a81a13fb..732e7a690 100644
--- a/controller/ovn-controller.c
+++ b/controller/ovn-controller.c
@@ -105,7 +105,6 @@ static unixctl_cb_func debug_ignore_startup_delay;
#define DEFAULT_BRIDGE_NAME "br-int"
#define DEFAULT_DATAPATH "system"
-#define OFCTRL_DEFAULT_PROBE_INTERVAL_SEC 0
#define CONTROLLER_LOOP_STOPWATCH_NAME "flow-generation"
#define OFCTRL_PUT_STOPWATCH_NAME "flow-installation"
@@ -556,22 +555,6 @@ update_ssl_config(const struct ovsrec_ssl_table *ssl_table)
}
}
-static int
-get_ofctrl_probe_interval(struct ovsdb_idl *ovs_idl)
-{
-const struct ovsrec_open_vswitch *cfg = ovsrec_open_vswitch_first(ovs_idl);
-if (!cfg) {
-
Re: [ovs-dev] [PATCH ovn v2] northd: match only on supported protocols to handle_svc_check
Thanks, Dumitru! > On 8 Jun 2023, at 16:31, Dumitru Ceara wrote: > > On 5/30/23 14:41, Vladislav Odintsov wrote: >> Depending on the udp service, it can reply with some udp data. >> In that case ovn-controller will warn with next message: >> >> pinctrl(ovn_pinctrl0)|WARN|handle service check: Unsupported protocol - [11] >> >> This is not something abnormal, so it needs to be fixed. >> With this patch ovn-northd changes match of appropriate lflow, which sends >> traffic to ovn-controller's pinctrl thread to handle_svc_check action. >> Now only supported protocols allowed to reach ovn-controller when destined >> to $svc_monitor_mac (tcp, icmp, icmpv6). >> >> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1913162 >> Signed-off-by: Vladislav Odintsov >> --- >> v1 -> v2: >> - Addressed Dumitru's suggestion to match on supported protocols >>instead of validating protocol inside pinctrl thread. >> --- > > Applied to main and backported to all stable branches down to 22.03, thanks! > > ___ > dev mailing list > d...@openvswitch.org <mailto:d...@openvswitch.org> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 1/2] utilities: add "--detach" option to ovs-ctl
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
---
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|noRun 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
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH 2/2] utilities: add --in-db-ssl option to ovs-ctl
It is possible to parametrize ovs-ctl script to start ovsdb-server with
DB_SCHEME other than Open_vSwitch. This scheme may not have currently
required table "SSL" with "key", "cert" and "cacert" columns.
This patch adds configuration knob "--in-db-ssl", which has default
behavior as it is now: run ovsdb server with ssl options.
User must pass "--in-db-ssl=no" to run ovsdb-server without these
arguments.
Signed-off-by: Vladislav Odintsov
---
utilities/ovs-ctl.in | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
index 72c8881e3..44a6496ef 100644
--- a/utilities/ovs-ctl.in
+++ b/utilities/ovs-ctl.in
@@ -150,9 +150,11 @@ do_start_ovsdb () {
fi
set "$@" -vconsole:emer -vsyslog:err -vfile:info
set "$@" --remote=punix:"$DB_SOCK"
-set "$@" --private-key=db:Open_vSwitch,SSL,private_key
-set "$@" --certificate=db:Open_vSwitch,SSL,certificate
-set "$@" --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert
+if test X"$IN_DB_SSL" = Xyes; then
+set "$@" --private-key=db:Open_vSwitch,SSL,private_key
+set "$@" --certificate=db:Open_vSwitch,SSL,certificate
+set "$@" --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert
+fi
[ "$OVS_USER" != "" ] && set "$@" --user "$OVS_USER"
[ "$OVSDB_SERVER_OPTIONS" != "" ] && set "$@" $OVSDB_SERVER_OPTIONS
@@ -356,6 +358,7 @@ set_defaults () {
DB_SOCK=$rundir/db.sock
DB_SCHEMA=$datadir/vswitch.ovsschema
EXTRA_DBS=
+IN_DB_SSL=yes
PROTOCOL=gre
DPORT=
@@ -457,6 +460,8 @@ File location options:
--db-file=FILE database file name (default: $DB_FILE)
--db-sock=SOCKET JSON-RPC socket name (default: $DB_SOCK)
--db-schema=FILE database schema file name (default: $DB_SCHEMA)
+ --in-db-ssl=yes|no use ssl key, cert and cacert file paths from Open_vSwitch
+ database (default: $IN_DB_SSL)
Options for "enable-protocol":
--protocol=PROTOCOL protocol to enable with iptables (default: gre)
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [ovn] ha-chassis-group false positive failover
Hi Han, thanks for your inputs! Please see comments inline. > On 5 Jun 2023, at 21:01, Han Zhou wrote: > > On Mon, Jun 5, 2023 at 8:58 AM Vladislav Odintsov <mailto:odiv...@gmail.com>> wrote: >> >> Hi Dumitru, Ilya, Han, >> >> do you guys have any comments here? >> I’m gonna start working on this change in near future... >> >> Thank you. >> >> On 17 May 2023, at 18:34, Numan Siddique > <mailto:num...@ovn.org>> wrote: >> >> On Wed, May 17, 2023 at 4:44 AM Vladislav Odintsov > <mailto:odiv...@gmail.com>> > wrote: >> >> >> >> >> On 16 May 2023, at 23:54, Numan Siddique > <mailto:num...@ovn.org>> wrote: >> >> Hi Vladislav, >> >> Sorry for the late reply. >> >> PSB for few comments. >> >> >> >> Thanks for your reply! >> My answers are inline. >> >> >> >> >> On Tue, May 16, 2023 at 3:42 PM Vladislav Odintsov > <mailto:odiv...@gmail.com> > <mailto:odiv...@gmail.com>> wrote: >> >> >> Hi Numan, Dumitru, Ilya, >> >> I guess I’ve managed to deal with some of these problems and have some > conclusions. >> Please see inline. >> >> On 14 Apr 2023, at 16:26, Vladislav Odintsov > <mailto:odiv...@gmail.com>> wrote: >> >> And as a follow-up, I see sometimes next error message in ovn-controller > log, though there is a configured much higher limit in seconds for > inactivity probe value for the chassis: >> >> >> ovn-controller establishes 3 openflow connections to local ovs-vswitchd > for next purposes: >> 1. openflow rules management (openflow probe interval is configured > through ovn-openflow-probe-interval external_ids setting [1]; default — > disabled [2]); >> 2. openflow features collection (hardcoded probe interval 5s [3]); >> 3. pinctrl thread (hardcoded probe interval 5s [4]). >> >> ovs|04426|rconn|ERR|unix:/run/openvswitch/br-int.mgmt: no response to > inactivity probe after 8 seconds, disconnecting >> >> ovs|26560|rconn|ERR|unix:/run/openvswitch/br-int.mgmt: no response to > inactivity probe after 10 seconds, disconnecting >> >> >> These messages most likely related to the connection for features > collection or pinctrl thread. So ovn-openflow-probe-interval has no matter > here. >> >> >> server with first log message: >> # ovs-vsctl get open . external_ids:ovn-openflow-probe-interval >> "30" >> >> server with second log message: >> # ovs-vsctl get open . external_ids:ovn-openflow-probe-interval >> "60" >> >> >> >> On 30 Mar 2023, at 23:19, Vladislav Odintsov > <mailto:odiv...@gmail.com>> wrote: >> >> Hi all, >> >> I’m facing a false positive failover in the event of openflow connection > got dropped after inactivity probe timeout due to high load of > ovn-controller handling huge amount of ovsdb updates. >> I wonder wether its a bug or I have to tune any specifics. See > ovn-controller logs: >> >> 2023-03-30T07:57:24.469Z|58440|inc_proc_eng|INFO|node: > logical_flow_output, recompute (failed handler for input port_groups) took > 35774ms >> 2023-03-30T07:57:28.521Z|58441|lflow_cache|INFO|Detected cache inactivity > (last active 40006 ms ago): trimming cache >> 2023-03-30T07:57:28.528Z|58442|timeval|WARN|Unreasonably long 40084ms > poll interval (32947ms user, 6968ms system) >> 2023-03-30T07:57:28.528Z|58443|timeval|WARN|faults: 43468 minor, 0 major >> ….. >> 2023-03-30T07:57:48.784Z|58496|reconnect|ERR|ssl::6642: no response > to inactivity probe after 60.2 seconds, disconnecting >> 2023-03-30T07:57:48.784Z|58497|reconnect|INFO|ssl::6642: connection > dropped >> 2023-03-30T07:57:48.905Z|58498|main|INFO|OVNSB commit failed, force > recompute next time. >> 2023-03-30T07:57:49.786Z|58499|reconnect|INFO|ssl::6642: connecting... >> 2023-03-30T07:57:49.924Z|58500|reconnect|INFO|ssl::6642: connected >> 2023-03-30T07:57:29.781Z|58501|poll_loop|INFO|wakeup due to 0-ms timeout > at lib/stream-ssl.c:838 (74% CPU usage) >> 2023-03-30T07:57:29.836Z|58502|poll_loop|INFO|wakeup due to 0-ms timeout > at lib/stream-ssl.c:838 (74% CPU usage) >> …. >> 2023-03-30T07:57:05.976Z|58545|poll_loop|INFO|wakeup due to 0-ms timeout > at lib/stream-ssl.c:838 (101% CPU usage) >> 2023-03-30T07:57:07.002Z|58546|memory|INFO|peak resident set size grew > 54% in last 682257.2 seconds, from 4435696 kB to 6824820 kB >> > 2023-03-30T07:57:07.002Z|58547|memory|INFO|
Re: [ovs-dev] [ovn] ha-chassis-group false positive failover
Hi Dumitru, Ilya, Han, do you guys have any comments here? I’m gonna start working on this change in near future... Thank you. > On 17 May 2023, at 18:34, Numan Siddique wrote: > > On Wed, May 17, 2023 at 4:44 AM Vladislav Odintsov <mailto:odiv...@gmail.com>> wrote: >> >> >> >>> On 16 May 2023, at 23:54, Numan Siddique wrote: >>> >>> Hi Vladislav, >>> >>> Sorry for the late reply. >>> >>> PSB for few comments. >> >> >> Thanks for your reply! >> My answers are inline. >> >>> >>> >>> >>> On Tue, May 16, 2023 at 3:42 PM Vladislav Odintsov >> <mailto:odiv...@gmail.com>> wrote: >>>> >>>> Hi Numan, Dumitru, Ilya, >>>> >>>> I guess I’ve managed to deal with some of these problems and have some >>>> conclusions. >>>> Please see inline. >>>> >>>>> On 14 Apr 2023, at 16:26, Vladislav Odintsov wrote: >>>>> >>>>> And as a follow-up, I see sometimes next error message in ovn-controller >>>>> log, though there is a configured much higher limit in seconds for >>>>> inactivity probe value for the chassis: >>>>> >>>> >>>> ovn-controller establishes 3 openflow connections to local ovs-vswitchd >>>> for next purposes: >>>> 1. openflow rules management (openflow probe interval is configured >>>> through ovn-openflow-probe-interval external_ids setting [1]; default — >>>> disabled [2]); >>>> 2. openflow features collection (hardcoded probe interval 5s [3]); >>>> 3. pinctrl thread (hardcoded probe interval 5s [4]). >>>> >>>>> ovs|04426|rconn|ERR|unix:/run/openvswitch/br-int.mgmt: no response to >>>>> inactivity probe after 8 seconds, disconnecting >>>>> >>>>> ovs|26560|rconn|ERR|unix:/run/openvswitch/br-int.mgmt: no response to >>>>> inactivity probe after 10 seconds, disconnecting >>>>> >>>> >>>> These messages most likely related to the connection for features >>>> collection or pinctrl thread. So ovn-openflow-probe-interval has no matter >>>> here. >>>> >>>>> >>>>> server with first log message: >>>>> # ovs-vsctl get open . external_ids:ovn-openflow-probe-interval >>>>> "30" >>>>> >>>>> server with second log message: >>>>> # ovs-vsctl get open . external_ids:ovn-openflow-probe-interval >>>>> "60" >>>>> >>>>> >>>>> >>>>>> On 30 Mar 2023, at 23:19, Vladislav Odintsov wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I’m facing a false positive failover in the event of openflow connection >>>>>> got dropped after inactivity probe timeout due to high load of >>>>>> ovn-controller handling huge amount of ovsdb updates. >>>>>> I wonder wether its a bug or I have to tune any specifics. See >>>>>> ovn-controller logs: >>>>>> >>>>>> 2023-03-30T07:57:24.469Z|58440|inc_proc_eng|INFO|node: >>>>>> logical_flow_output, recompute (failed handler for input port_groups) >>>>>> took 35774ms >>>>>> 2023-03-30T07:57:28.521Z|58441|lflow_cache|INFO|Detected cache >>>>>> inactivity (last active 40006 ms ago): trimming cache >>>>>> 2023-03-30T07:57:28.528Z|58442|timeval|WARN|Unreasonably long 40084ms >>>>>> poll interval (32947ms user, 6968ms system) >>>>>> 2023-03-30T07:57:28.528Z|58443|timeval|WARN|faults: 43468 minor, 0 major >>>>>> ….. >>>>>> 2023-03-30T07:57:48.784Z|58496|reconnect|ERR|ssl::6642: no response >>>>>> to inactivity probe after 60.2 seconds, disconnecting >>>>>> 2023-03-30T07:57:48.784Z|58497|reconnect|INFO|ssl::6642: connection >>>>>> dropped >>>>>> 2023-03-30T07:57:48.905Z|58498|main|INFO|OVNSB commit failed, force >>>>>> recompute next time. >>>>>> 2023-03-30T07:57:49.786Z|58499|reconnect|INFO|ssl::6642: >>>>>> connecting... >>>>>> 2023-03-30T07:57:49.924Z|58500|reconnect|INFO|ssl::6642: connected >>>>>> 2023-03-30T07:57:29.781Z|58501|poll_loop|INFO|wakeup due
Re: [ovs-dev] [PATCH ovn 5/5] controller, northd: pass arp/nd from HW VTEP to lrouter pipeline
v2 of patch #5 was submitted:
https://patchwork.ozlabs.org/project/ovn/patch/20230530150328.1224972-1-odiv...@gmail.com/
> On 30 May 2023, at 13:12, Vladislav Odintsov wrote:
>
>
>
>> On 30 May 2023, at 13:10, Dumitru Ceara wrote:
>>
>> On 5/30/23 11:59, Vladislav Odintsov wrote:
>>> Hi Dumitru,
>>>
>>> thanks for the review!
>>> My answers are inline.
>>>
>>>> On 30 May 2023, at 12:27, Dumitru Ceara wrote:
>>>>
>>>> On 5/19/23 20:18, Vladislav Odintsov wrote:
>>>>> This patch is intended to make next two changes:
>>>>>
>>>>> 1. Support create/update of MAC_Binding for GARP/ND from HW VTEP.
>>>>>
>>>>> Prior to this patch MAC_Binding records were created only when LRP issued
>>>>> ARP request/Neighbor solicitation. If IP to MAC in network attached via
>>>>> vtep lport was changed the old MAC_Binding prevented normal
>>>>> communication. Now router port (chassisredirect) in logical switch with
>>>>> vtep lport catches GARP or Neighbor Solicitation and updates MAC_Binding.
>>>>>
>>>>> New flow with max priority was added in ls_in_arp_nd_resp and additional
>>>>> OF rule in table 37 (OFTABLE_REMOTE_OUTPUT) to process multicast packets
>>>>> received from RAMP_SWITCH.
>>>>>
>>>>> 2. Answer to ARP/ND on requests coming from HW VTEP in lrouter pipeline.
>>>>>
>>>>> This is needed to reduce duplicated arp-responses, which were generated
>>>>> by OVN arp-responder flows in node, where chassisredirect port located
>>>>> with responses coming directly from VM interfaces.
>>>>>
>>>>> As a result of this change, now vifs located on same chassis, where
>>>>> chassisredirect ports are located receive ARP/ND mcast packets, which
>>>>> previously were suppressed by arp-responder on the node.
>>>>>
>>>>> Tests and documentation were updated to conform to new behaviour.
>>>>>
>>>>> Signed-off-by: Vladislav Odintsov
>>>>> ---
>>>>
>>>> Hi Vladislav,
>>>>
>>>> Thanks for the patch.
>>>>
>>>>> controller/binding.c| 48
>>>>> controller/local_data.h | 3 ++
>>>>> controller/physical.c | 46 +--
>>>>> northd/northd.c | 10 +
>>>>> northd/ovn-northd.8.xml | 6 +++
>>>>> tests/ovn.at <http://ovn.at/>| 99
>>>>> -
>>>>
>>>> Could you please add a NEWS entry for this behavior change?
>>>
>>> Sure, will do it in v2.
>>>
>>>>
>>>>> 6 files changed, 207 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/controller/binding.c b/controller/binding.c
>>>>> index c7a2b3f10..5932ad785 100644
>>>>> --- a/controller/binding.c
>>>>> +++ b/controller/binding.c
>>>>> @@ -509,6 +509,30 @@ update_ld_multichassis_ports(const struct
>>>>> sbrec_port_binding *binding_rec,
>>>>>}
>>>>> }
>>>>>
>>>>> +static void
>>>>> +update_ld_vtep_port(const struct sbrec_port_binding *binding_rec,
>>>>> +struct hmap *local_datapaths)
>>>>> +{
>>>>> +struct local_datapath *ld
>>>>> += get_local_datapath(local_datapaths,
>>>>> + binding_rec->datapath->tunnel_key);
>>>>> +if (!ld) {
>>>>> +return;
>>>>> +}
>>>>> +
>>>>> +if (ld->vtep_port && strcmp(ld->vtep_port->logical_port,
>>>>> +binding_rec->logical_port)) {
>>>>> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
>>>>> +VLOG_WARN_RL(&rl, "vtep port '%s' already set for datapath "
>>>>> + "'%"PRId64"', skipping the new port '%s'.",
>>>>> + ld->vtep_port->logical_port,
>>>>> + binding_rec->datapath->tunnel_key,
>>>>> + binding_rec->logical_port)
[ovs-dev] [PATCH ovn v2] controller, northd: pass arp/nd from HW VTEP to lrouter pipeline
This patch is intended to make next two changes:
1. Support create/update of MAC_Binding for GARP/ND from HW VTEP.
Prior to this patch MAC_Binding records were created only when LRP issued
ARP request/Neighbor solicitation. If IP to MAC in network attached via
vtep lport was changed the old MAC_Binding prevented normal
communication. Now router port (chassisredirect) in logical switch with
vtep lport catches GARP or Neighbor Solicitation and updates MAC_Binding.
New flow with max priority was added in ls_in_arp_nd_resp and additional
OF rule in table 37 (OFTABLE_REMOTE_OUTPUT) to process multicast packets
received from RAMP_SWITCH.
2. Answer to ARP/ND on requests coming from HW VTEP in lrouter pipeline.
This is needed to reduce duplicated arp-responses, which were generated
by OVN arp-responder flows in node, where chassisredirect port located
with responses coming directly from VM interfaces.
As a result of this change, now vifs located on same chassis, where
chassisredirect ports are located receive ARP/ND mcast packets, which
previously were suppressed by arp-responder on the node.
Tests and documentation were updated to conform to new behaviour.
Signed-off-by: Vladislav Odintsov
---
v1 -> v2:
- Addressed Dumitru's review comments.
---
NEWS| 2 +
controller/binding.c| 47 +++
controller/local_data.h | 3 ++
controller/physical.c | 45 ++-
northd/northd.c | 10 +
northd/ovn-northd.8.xml | 6 +++
tests/ovn.at| 99 -
7 files changed, 208 insertions(+), 4 deletions(-)
diff --git a/NEWS b/NEWS
index ec79e5fe7..2c31e5259 100644
--- a/NEWS
+++ b/NEWS
@@ -37,6 +37,8 @@ OVN v23.06.0 - xx xxx
- Support for tiered ACLs has been added. This allows for ACLs to be layered
into separate tiers of priority. For more information, please see the
ovn-nb and ovn-northd manpages.
+ - Support to create/update MAC_Binding when GARP received from VTEP (RAMP)
+switch on l3dgw port.
OVN v23.03.0 - 03 Mar 2023
--
diff --git a/controller/binding.c b/controller/binding.c
index c7a2b3f10..a90466bd6 100644
--- a/controller/binding.c
+++ b/controller/binding.c
@@ -509,6 +509,30 @@ update_ld_multichassis_ports(const struct
sbrec_port_binding *binding_rec,
}
}
+static void
+update_ld_vtep_port(const struct sbrec_port_binding *binding_rec,
+struct hmap *local_datapaths)
+{
+struct local_datapath *ld
+= get_local_datapath(local_datapaths,
+ binding_rec->datapath->tunnel_key);
+if (!ld) {
+return;
+}
+
+if (ld->vtep_port && strcmp(ld->vtep_port->logical_port,
+binding_rec->logical_port)) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
+VLOG_WARN_RL(&rl, "vtep port '%s' already set for datapath "
+ "'%"PRId64"', skipping the new port '%s'.",
+ ld->vtep_port->logical_port,
+ binding_rec->datapath->tunnel_key,
+ binding_rec->logical_port);
+return;
+}
+ld->vtep_port = binding_rec;
+}
+
static void
update_ld_localnet_port(const struct sbrec_port_binding *binding_rec,
struct shash *bridge_mappings,
@@ -1987,6 +2011,7 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct
binding_ctx_out *b_ctx_out)
struct ovs_list external_lports = OVS_LIST_INITIALIZER(&external_lports);
struct ovs_list multichassis_ports = OVS_LIST_INITIALIZER(
&multichassis_ports);
+struct ovs_list vtep_lports = OVS_LIST_INITIALIZER(&vtep_lports);
struct lport {
struct ovs_list list_node;
@@ -2010,8 +2035,13 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct
binding_ctx_out *b_ctx_out)
switch (lport_type) {
case LP_PATCH:
+update_related_lport(pb, b_ctx_out);
+break;
case LP_VTEP:
update_related_lport(pb, b_ctx_out);
+struct lport *vtep_lport = xmalloc(sizeof *vtep_lport);
+vtep_lport->pb = pb;
+ovs_list_push_back(&vtep_lports, &vtep_lport->list_node);
break;
case LP_LOCALPORT:
@@ -2111,6 +2141,15 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct
binding_ctx_out *b_ctx_out)
free(multichassis_lport);
}
+/* Run through vtep lport list to see if there are vtep ports
+ * on local datapaths discovered from above loop, and update the
+ * corresponding local datapath accordingly. */
+struct lport *vtep_lport;
+LIST_FOR_EACH_POP (vtep_lport, list_node, &vtep_lports) {
+update_ld_vtep_port(vtep_
Re: [ovs-dev] [PATCH ovn] controller: don't report UDP as unsupported proto in svc_check
Hi Dumitru,
I agree with the requested changes, such approach seems much better.
I’ve reworked patch and just sent v2. Please, check it out:
https://patchwork.ozlabs.org/project/ovn/patch/20230530124157.1223591-1-odiv...@gmail.com/
> On 30 May 2023, at 12:44, Dumitru Ceara wrote:
>
> On 5/24/23 13:03, Ales Musil wrote:
>> On Mon, May 22, 2023 at 11:18 PM Vladislav Odintsov
>> wrote:
>>
>>> Depending on the udp service, it can reply with some udp data.
>>> In that case ovn-controller will warn with next message:
>>>
>>> pinctrl(ovn_pinctrl0)|WARN|handle service check: Unsupported protocol -
>>> [11]
>>>
>>> With this patch ovn-controller ignores UDP packets, which came to
>>> pinctrl_handle_svc_check(). This is not something abnormal, so don't
>>> write warnings.
>>>
>>> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1913162
>>> Signed-off-by: Vladislav Odintsov
>>> ---
>>> controller/pinctrl.c | 7 +++
>>> 1 file changed, 7 insertions(+)
>>>
>>> diff --git a/controller/pinctrl.c b/controller/pinctrl.c
>>> index b4be22020..f2e753cdb 100644
>>> --- a/controller/pinctrl.c
>>> +++ b/controller/pinctrl.c
>>> @@ -,6 +,13 @@ pinctrl_handle_svc_check(struct rconn *swconn,
>>> const struct flow *ip_flow,
>>> ip_proto = in_ip->ip6_nxt;
>>> }
>>>
>>> +if (ip_proto == IPPROTO_UDP) {
>>> +/* We should do nothing if we got UDP packet.
>>> + * If service is running, it can respond with any UDP data,
>>> + * so just ingore it. */
>>> + return;
>>> +}
>>> +
>>> if (ip_proto != IPPROTO_TCP && ip_proto != IPPROTO_ICMP &&
>>> ip_proto != IPPROTO_ICMPV6) {
>>> static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
>>> --
>>> 2.36.1
>>>
>>> ___
>>> dev mailing list
>>> d...@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>
>>>
>> Looks good to me, thanks.
>>
>> Acked-by: Ales Musil
>>
>
> Hi, Vladislav, Ales,
>
> I think it might be better to just restrict the logical flow condition
> to the type of traffic we actually want to handle in slow path (in
> pinctrl).
>
> That is, this flow (and the others that match on ethernet destination
> being equal to $svc_monitor_mac):
>
>ovn_lflow_add(lflows, od, S_SWITCH_IN_L2_LKUP, 110,
> "eth.dst == $svc_monitor_mac",
> "handle_svc_check(inport);");
>
> should probably be changed to explicitly match on the supported protocol
> list, e.g.:
>
>ovn_lflow_add(lflows, od, S_SWITCH_IN_L2_LKUP, 110,
> "eth.dst == $svc_monitor_mac && (tcp || icmp || icmp6)",
> "handle_svc_check(inport);");
>
> Thanks,
> Dumitru
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Regards,
Vladislav Odintsov
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn v2] northd: match only on supported protocols to handle_svc_check
Depending on the udp service, it can reply with some udp data. In that case ovn-controller will warn with next message: pinctrl(ovn_pinctrl0)|WARN|handle service check: Unsupported protocol - [11] This is not something abnormal, so it needs to be fixed. With this patch ovn-northd changes match of appropriate lflow, which sends traffic to ovn-controller's pinctrl thread to handle_svc_check action. Now only supported protocols allowed to reach ovn-controller when destined to $svc_monitor_mac (tcp, icmp, icmpv6). Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1913162 Signed-off-by: Vladislav Odintsov --- v1 -> v2: - Addressed Dumitru's suggestion to match on supported protocols instead of validating protocol inside pinctrl thread. --- northd/northd.c | 2 +- tests/ovn-northd.at | 30 +++--- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/northd/northd.c b/northd/northd.c index a6eca916b..c459887b7 100644 --- a/northd/northd.c +++ b/northd/northd.c @@ -9124,7 +9124,7 @@ build_lswitch_destination_lookup_bmcast(struct ovn_datapath *od, ovs_assert(od->nbs); ovn_lflow_add(lflows, od, S_SWITCH_IN_L2_LKUP, 110, - "eth.dst == $svc_monitor_mac", + "eth.dst == $svc_monitor_mac && (tcp || icmp || icmp6)", "handle_svc_check(inport);"); struct mcast_switch_info *mcast_sw_info = &od->mcast_info.sw; diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at index e3669bdf5..8eadad8bf 100644 --- a/tests/ovn-northd.at +++ b/tests/ovn-northd.at @@ -4974,7 +4974,7 @@ check ovn-nbctl lsp-set-options ls2-ro2 router-port=ro2-ls2 ovn-sbctl lflow-list ls1 > ls1_lflows AT_CHECK([grep "ls_in_l2_lkup" ls1_lflows | sed 's/table=../table=??/' | sort], [0], [dnl table=??(ls_in_l2_lkup ), priority=0, match=(1), action=(outport = get_fdb(eth.dst); next;) - table=??(ls_in_l2_lkup ), priority=110 , match=(eth.dst == $svc_monitor_mac), action=(handle_svc_check(inport);) + table=??(ls_in_l2_lkup ), priority=110 , match=(eth.dst == $svc_monitor_mac && (tcp || icmp || icmp6)), action=(handle_svc_check(inport);) table=??(ls_in_l2_lkup ), priority=50 , match=(eth.dst == 00:00:00:00:01:01), action=(outport = "ls1-ro1"; output;) table=??(ls_in_l2_lkup ), priority=50 , match=(eth.dst == 00:00:00:00:01:02), action=(outport = "vm1"; output;) table=??(ls_in_l2_lkup ), priority=70 , match=(eth.mcast), action=(outport = "_MC_flood"; output;) @@ -4986,7 +4986,7 @@ AT_CHECK([grep "ls_in_l2_lkup" ls1_lflows | sed 's/table=../table=??/' | sort], ovn-sbctl lflow-list ls2 > ls2_lflows AT_CHECK([grep "ls_in_l2_lkup" ls2_lflows | sed 's/table=../table=??/' | sort], [0], [dnl table=??(ls_in_l2_lkup ), priority=0, match=(1), action=(outport = get_fdb(eth.dst); next;) - table=??(ls_in_l2_lkup ), priority=110 , match=(eth.dst == $svc_monitor_mac), action=(handle_svc_check(inport);) + table=??(ls_in_l2_lkup ), priority=110 , match=(eth.dst == $svc_monitor_mac && (tcp || icmp || icmp6)), action=(handle_svc_check(inport);) table=??(ls_in_l2_lkup ), priority=50 , match=(eth.dst == 00:00:00:00:02:01), action=(outport = "ls2-ro2"; output;) table=??(ls_in_l2_lkup ), priority=50 , match=(eth.dst == 00:00:00:00:02:02), action=(outport = "vm2"; output;) table=??(ls_in_l2_lkup ), priority=70 , match=(eth.mcast), action=(outport = "_MC_flood"; output;) @@ -5006,7 +5006,7 @@ check ovn-nbctl --wait=sb lr-nat-add ro2 snat 20.0.0.200 192.168.2.200/30 ovn-sbctl lflow-list ls1 > ls1_lflows AT_CHECK([grep "ls_in_l2_lkup" ls1_lflows | sed 's/table=../table=??/' | sort], [0], [dnl table=??(ls_in_l2_lkup ), priority=0, match=(1), action=(outport = get_fdb(eth.dst); next;) - table=??(ls_in_l2_lkup ), priority=110 , match=(eth.dst == $svc_monitor_mac), action=(handle_svc_check(inport);) + table=??(ls_in_l2_lkup ), priority=110 , match=(eth.dst == $svc_monitor_mac && (tcp || icmp || icmp6)), action=(handle_svc_check(inport);) table=??(ls_in_l2_lkup ), priority=50 , match=(eth.dst == 00:00:00:00:01:01), action=(outport = "ls1-ro1"; output;) table=??(ls_in_l2_lkup ), priority=50 , match=(eth.dst == 00:00:00:00:01:02), action=(outport = "vm1"; output;) table=??(ls_in_l2_lkup ), priority=70 , match=(eth.mcast), action=(outport = "_MC_flood"; output;) @@ -5019,7 +5019,7 @@ AT_CHECK([grep "ls_in_l2_lkup" ls1_lflows | sed 's/table=../table=??/' | sort], ovn-sbctl lflow-list ls2 > ls2_lflows AT_CHECK([grep "ls_in_l2_lkup" ls2_lflows | sed 's/table=../table=??/' | so
Re: [ovs-dev] [PATCH ovn 5/5] controller, northd: pass arp/nd from HW VTEP to lrouter pipeline
> On 30 May 2023, at 13:10, Dumitru Ceara wrote:
>
> On 5/30/23 11:59, Vladislav Odintsov wrote:
>> Hi Dumitru,
>>
>> thanks for the review!
>> My answers are inline.
>>
>>> On 30 May 2023, at 12:27, Dumitru Ceara wrote:
>>>
>>> On 5/19/23 20:18, Vladislav Odintsov wrote:
>>>> This patch is intended to make next two changes:
>>>>
>>>> 1. Support create/update of MAC_Binding for GARP/ND from HW VTEP.
>>>>
>>>> Prior to this patch MAC_Binding records were created only when LRP issued
>>>> ARP request/Neighbor solicitation. If IP to MAC in network attached via
>>>> vtep lport was changed the old MAC_Binding prevented normal
>>>> communication. Now router port (chassisredirect) in logical switch with
>>>> vtep lport catches GARP or Neighbor Solicitation and updates MAC_Binding.
>>>>
>>>> New flow with max priority was added in ls_in_arp_nd_resp and additional
>>>> OF rule in table 37 (OFTABLE_REMOTE_OUTPUT) to process multicast packets
>>>> received from RAMP_SWITCH.
>>>>
>>>> 2. Answer to ARP/ND on requests coming from HW VTEP in lrouter pipeline.
>>>>
>>>> This is needed to reduce duplicated arp-responses, which were generated
>>>> by OVN arp-responder flows in node, where chassisredirect port located
>>>> with responses coming directly from VM interfaces.
>>>>
>>>> As a result of this change, now vifs located on same chassis, where
>>>> chassisredirect ports are located receive ARP/ND mcast packets, which
>>>> previously were suppressed by arp-responder on the node.
>>>>
>>>> Tests and documentation were updated to conform to new behaviour.
>>>>
>>>> Signed-off-by: Vladislav Odintsov
>>>> ---
>>>
>>> Hi Vladislav,
>>>
>>> Thanks for the patch.
>>>
>>>> controller/binding.c| 48
>>>> controller/local_data.h | 3 ++
>>>> controller/physical.c | 46 +--
>>>> northd/northd.c | 10 +
>>>> northd/ovn-northd.8.xml | 6 +++
>>>> tests/ovn.at <http://ovn.at/>| 99
>>>> -
>>>
>>> Could you please add a NEWS entry for this behavior change?
>>
>> Sure, will do it in v2.
>>
>>>
>>>> 6 files changed, 207 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/controller/binding.c b/controller/binding.c
>>>> index c7a2b3f10..5932ad785 100644
>>>> --- a/controller/binding.c
>>>> +++ b/controller/binding.c
>>>> @@ -509,6 +509,30 @@ update_ld_multichassis_ports(const struct
>>>> sbrec_port_binding *binding_rec,
>>>> }
>>>> }
>>>>
>>>> +static void
>>>> +update_ld_vtep_port(const struct sbrec_port_binding *binding_rec,
>>>> +struct hmap *local_datapaths)
>>>> +{
>>>> +struct local_datapath *ld
>>>> += get_local_datapath(local_datapaths,
>>>> + binding_rec->datapath->tunnel_key);
>>>> +if (!ld) {
>>>> +return;
>>>> +}
>>>> +
>>>> +if (ld->vtep_port && strcmp(ld->vtep_port->logical_port,
>>>> +binding_rec->logical_port)) {
>>>> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
>>>> +VLOG_WARN_RL(&rl, "vtep port '%s' already set for datapath "
>>>> + "'%"PRId64"', skipping the new port '%s'.",
>>>> + ld->vtep_port->logical_port,
>>>> + binding_rec->datapath->tunnel_key,
>>>> + binding_rec->logical_port);
>>>> +return;
>>>> +}
>>>> +ld->vtep_port = binding_rec;
>>>> +}
>>>> +
>>>> static void
>>>> update_ld_localnet_port(const struct sbrec_port_binding *binding_rec,
>>>> struct shash *bridge_mappings,
>>>> @@ -1987,6 +2011,7 @@ binding_run(struct binding_ctx_in *b_ctx_in,
>>>> struct binding_ctx_out *b_ctx_out)
>>>> struct ovs_list external_lports =
>>>> OVS_L
Re: [ovs-dev] [PATCH ovn 5/5] controller, northd: pass arp/nd from HW VTEP to lrouter pipeline
Hi Dumitru,
thanks for the review!
My answers are inline.
> On 30 May 2023, at 12:27, Dumitru Ceara wrote:
>
> On 5/19/23 20:18, Vladislav Odintsov wrote:
>> This patch is intended to make next two changes:
>>
>> 1. Support create/update of MAC_Binding for GARP/ND from HW VTEP.
>>
>> Prior to this patch MAC_Binding records were created only when LRP issued
>> ARP request/Neighbor solicitation. If IP to MAC in network attached via
>> vtep lport was changed the old MAC_Binding prevented normal
>> communication. Now router port (chassisredirect) in logical switch with
>> vtep lport catches GARP or Neighbor Solicitation and updates MAC_Binding.
>>
>> New flow with max priority was added in ls_in_arp_nd_resp and additional
>> OF rule in table 37 (OFTABLE_REMOTE_OUTPUT) to process multicast packets
>> received from RAMP_SWITCH.
>>
>> 2. Answer to ARP/ND on requests coming from HW VTEP in lrouter pipeline.
>>
>> This is needed to reduce duplicated arp-responses, which were generated
>> by OVN arp-responder flows in node, where chassisredirect port located
>> with responses coming directly from VM interfaces.
>>
>> As a result of this change, now vifs located on same chassis, where
>> chassisredirect ports are located receive ARP/ND mcast packets, which
>> previously were suppressed by arp-responder on the node.
>>
>> Tests and documentation were updated to conform to new behaviour.
>>
>> Signed-off-by: Vladislav Odintsov
>> ---
>
> Hi Vladislav,
>
> Thanks for the patch.
>
>> controller/binding.c| 48
>> controller/local_data.h | 3 ++
>> controller/physical.c | 46 +--
>> northd/northd.c | 10 +
>> northd/ovn-northd.8.xml | 6 +++
>> tests/ovn.at <http://ovn.at/>| 99
>> -
>
> Could you please add a NEWS entry for this behavior change?
Sure, will do it in v2.
>
>> 6 files changed, 207 insertions(+), 5 deletions(-)
>>
>> diff --git a/controller/binding.c b/controller/binding.c
>> index c7a2b3f10..5932ad785 100644
>> --- a/controller/binding.c
>> +++ b/controller/binding.c
>> @@ -509,6 +509,30 @@ update_ld_multichassis_ports(const struct
>> sbrec_port_binding *binding_rec,
>> }
>> }
>>
>> +static void
>> +update_ld_vtep_port(const struct sbrec_port_binding *binding_rec,
>> +struct hmap *local_datapaths)
>> +{
>> +struct local_datapath *ld
>> += get_local_datapath(local_datapaths,
>> + binding_rec->datapath->tunnel_key);
>> +if (!ld) {
>> +return;
>> +}
>> +
>> +if (ld->vtep_port && strcmp(ld->vtep_port->logical_port,
>> +binding_rec->logical_port)) {
>> +static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
>> +VLOG_WARN_RL(&rl, "vtep port '%s' already set for datapath "
>> + "'%"PRId64"', skipping the new port '%s'.",
>> + ld->vtep_port->logical_port,
>> + binding_rec->datapath->tunnel_key,
>> + binding_rec->logical_port);
>> +return;
>> +}
>> +ld->vtep_port = binding_rec;
>> +}
>> +
>> static void
>> update_ld_localnet_port(const struct sbrec_port_binding *binding_rec,
>> struct shash *bridge_mappings,
>> @@ -1987,6 +2011,7 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct
>> binding_ctx_out *b_ctx_out)
>> struct ovs_list external_lports = OVS_LIST_INITIALIZER(&external_lports);
>> struct ovs_list multichassis_ports = OVS_LIST_INITIALIZER(
>> &multichassis_ports);
>> +struct ovs_list vtep_lports = OVS_LIST_INITIALIZER(&vtep_lports);
>>
>> struct lport {
>> struct ovs_list list_node;
>> @@ -2010,8 +2035,13 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct
>> binding_ctx_out *b_ctx_out)
>>
>> switch (lport_type) {
>> case LP_PATCH:
>> +update_related_lport(pb, b_ctx_out);
>> +break;
>> case LP_VTEP:
>> update_related_lport(pb, b_ctx_out);
>> +struct lport *vtep_lport = xmalloc(sizeof *vtep_lport);
>> +vtep_lport->pb = pb;
>> +ovs_
[ovs-dev] [PATCH ovn] controller: don't report UDP as unsupported proto in svc_check
Depending on the udp service, it can reply with some udp data.
In that case ovn-controller will warn with next message:
pinctrl(ovn_pinctrl0)|WARN|handle service check: Unsupported protocol - [11]
With this patch ovn-controller ignores UDP packets, which came to
pinctrl_handle_svc_check(). This is not something abnormal, so don't
write warnings.
Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=1913162
Signed-off-by: Vladislav Odintsov
---
controller/pinctrl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/controller/pinctrl.c b/controller/pinctrl.c
index b4be22020..f2e753cdb 100644
--- a/controller/pinctrl.c
+++ b/controller/pinctrl.c
@@ -,6 +,13 @@ pinctrl_handle_svc_check(struct rconn *swconn, const
struct flow *ip_flow,
ip_proto = in_ip->ip6_nxt;
}
+if (ip_proto == IPPROTO_UDP) {
+/* We should do nothing if we got UDP packet.
+ * If service is running, it can respond with any UDP data,
+ * so just ingore it. */
+ return;
+}
+
if (ip_proto != IPPROTO_TCP && ip_proto != IPPROTO_ICMP &&
ip_proto != IPPROTO_ICMPV6) {
static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(1, 5);
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [ovn] help wanted: how MC_FLOOD actions works for eth.mcast traffic coming from localnet lports?
Finally, I’ve managed to find the correct place for this change. I’ve submitted a patch series here: [1] Thanks Dumitru, your help was very valuable! I’d be glad if you can find some time to review this series. :) 1: https://patchwork.ozlabs.org/project/ovn/cover/20230519181859.1195040-1-odiv...@gmail.com/ > On 17 May 2023, at 19:05, Vladislav Odintsov wrote: > > Thanks Dumitru for the response. > > I’ve looked through this code and even tried to implement similar logic for > vtep lport, but realized, that vtep mcast traffic is a bit different from > localnet port. > mcast traffic originated in normal vif port in localnet-attached lswitch has > two cases: > - if uplink bridge mapping is locally available, the mcast packet is sent to > this interface assuming classic network switch outside of ovn will flood it > in l2 domain > - if uplink bridge mapping is locally unawailable, such mcast packet is > flooded in overlay. (honestly I didn’t find code related to this logic, I’ve > found it just performing tests) > > With same logic implemented in consider_mc_group() the BUM traffic originated > in vif lport doesn’t reach remote chassis at all… > > With vtep lport mcast traffic must be replicated always on source node, but > it’s prohibited to re-send received from vtep lport mcast packets to other > remote chassis. > I guess I need to reject mcast l2 flood to remote ports if REGBIT_FROM_RAMP > == 1. > > Do you have an idea for the correct place to put such logic in? > >> On 16 May 2023, at 23:02, Dumitru Ceara wrote: >> >> On 5/16/23 21:48, Vladislav Odintsov wrote: >>> Hi Numan, Dumitru, Ilya, Mark, >>> >> >> Hi Vladislav, >> >>> if someone can help, I’ll be very grateful. >>> >>> Thanks in advance. >>> >>>> On 15 May 2023, at 15:06, Vladislav Odintsov wrote: >>>> >>>> Hi, I’m implementing neighbour learning on the chassis-redirect ports >>>> for traffic coming from lport of vtep type and have some >>>> misunderstanding of how MC_FLOOD action works with traffic coming from >>>> localnet lports. Imagine, we’ve got lswitch with 4 LSPs: - vtep lport >>>> (type vtep) - lrp (chassis-redirect configured router port on hv1) - >>>> lsp1 on hv1 - lsp2 on hv2 My problem is that mcast/bcast traffic >>>> coming from vtep lport got flooded to all logical ports of the >>>> lswitch, even for those which reside on another hypervisor (hv2 in >>>> this example), resulting in duplicated packets on lsp2 vif port. vtep >>>> switch performs source node replication of BUM traffic, so bcast >>>> packets reach normal vif lports + MC_FLOOD in ls_in_l2_lkup. I’m >>>> comparing behaviour with localnet port in same setup (lswitch with 2 >>>> LSPs on different hypervisors) and see there is no such behaviour: packets >>>> don’t get flooded to vif lports on other chassis. >>>> I see that eth.mcast traffic is matched in ls_in_l2_lkup lflow table with >>>> the action 'outport = "_MC_flood"; output;', then it got flooded to only >>>> LRPs of LS and *local* vif lports. The question is - where is the >>>> logic, which prevents flooding from localnet to vif located on other >>>> chassis? Am I missing something? Let me know if any additional >>>> information is needed. Thanks! >>>> >> >> For localnet ports the key is in how ovn-controllers expand (L2) >> multicast_groups. In consider_mc_group() [0]: >> >> /* Go through all of the ports in the multicast group: >>* >>*- For remote ports, add the chassis to 'remote_chassis' or >>* 'vtep_chassis'. >>* >>*- For local ports (other than logical patch ports), add actions >>* to 'ofpacts' to set the output port and resubmit. >>* >>*- For logical patch ports, add actions to 'remote_ofpacts' >>* instead. (If we put them in 'ofpacts', then the output >>* would happen on every hypervisor in the multicast group, >>* effectively duplicating the packet.) The only exception >>* is in case of transit switches (used by OVN-IC). We need >>* patch ports to be processed on the remote side, after >>* crossing the AZ boundary. >>* >>*- For chassisredirect ports, add actions to 'ofpacts' to >>* set the output port to be the router patch port for which >>* the redirect port was added. >>
[ovs-dev] [PATCH ovn 5/5] controller, northd: pass arp/nd from HW VTEP to lrouter pipeline
This patch is intended to make next two changes:
1. Support create/update of MAC_Binding for GARP/ND from HW VTEP.
Prior to this patch MAC_Binding records were created only when LRP issued
ARP request/Neighbor solicitation. If IP to MAC in network attached via
vtep lport was changed the old MAC_Binding prevented normal
communication. Now router port (chassisredirect) in logical switch with
vtep lport catches GARP or Neighbor Solicitation and updates MAC_Binding.
New flow with max priority was added in ls_in_arp_nd_resp and additional
OF rule in table 37 (OFTABLE_REMOTE_OUTPUT) to process multicast packets
received from RAMP_SWITCH.
2. Answer to ARP/ND on requests coming from HW VTEP in lrouter pipeline.
This is needed to reduce duplicated arp-responses, which were generated
by OVN arp-responder flows in node, where chassisredirect port located
with responses coming directly from VM interfaces.
As a result of this change, now vifs located on same chassis, where
chassisredirect ports are located receive ARP/ND mcast packets, which
previously were suppressed by arp-responder on the node.
Tests and documentation were updated to conform to new behaviour.
Signed-off-by: Vladislav Odintsov
---
controller/binding.c| 48
controller/local_data.h | 3 ++
controller/physical.c | 46 +--
northd/northd.c | 10 +
northd/ovn-northd.8.xml | 6 +++
tests/ovn.at| 99 -
6 files changed, 207 insertions(+), 5 deletions(-)
diff --git a/controller/binding.c b/controller/binding.c
index c7a2b3f10..5932ad785 100644
--- a/controller/binding.c
+++ b/controller/binding.c
@@ -509,6 +509,30 @@ update_ld_multichassis_ports(const struct
sbrec_port_binding *binding_rec,
}
}
+static void
+update_ld_vtep_port(const struct sbrec_port_binding *binding_rec,
+struct hmap *local_datapaths)
+{
+struct local_datapath *ld
+= get_local_datapath(local_datapaths,
+ binding_rec->datapath->tunnel_key);
+if (!ld) {
+return;
+}
+
+if (ld->vtep_port && strcmp(ld->vtep_port->logical_port,
+binding_rec->logical_port)) {
+static struct vlog_rate_limit rl = VLOG_RATE_LIMIT_INIT(5, 1);
+VLOG_WARN_RL(&rl, "vtep port '%s' already set for datapath "
+ "'%"PRId64"', skipping the new port '%s'.",
+ ld->vtep_port->logical_port,
+ binding_rec->datapath->tunnel_key,
+ binding_rec->logical_port);
+return;
+}
+ld->vtep_port = binding_rec;
+}
+
static void
update_ld_localnet_port(const struct sbrec_port_binding *binding_rec,
struct shash *bridge_mappings,
@@ -1987,6 +2011,7 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct
binding_ctx_out *b_ctx_out)
struct ovs_list external_lports = OVS_LIST_INITIALIZER(&external_lports);
struct ovs_list multichassis_ports = OVS_LIST_INITIALIZER(
&multichassis_ports);
+struct ovs_list vtep_lports = OVS_LIST_INITIALIZER(&vtep_lports);
struct lport {
struct ovs_list list_node;
@@ -2010,8 +2035,13 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct
binding_ctx_out *b_ctx_out)
switch (lport_type) {
case LP_PATCH:
+update_related_lport(pb, b_ctx_out);
+break;
case LP_VTEP:
update_related_lport(pb, b_ctx_out);
+struct lport *vtep_lport = xmalloc(sizeof *vtep_lport);
+vtep_lport->pb = pb;
+ovs_list_push_back(&vtep_lports, &vtep_lport->list_node);
break;
case LP_LOCALPORT:
@@ -2111,6 +2141,16 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct
binding_ctx_out *b_ctx_out)
free(multichassis_lport);
}
+/* Run through vtep lport list to see if there are vtep ports
+ * on local datapaths discovered from above loop, and update the
+ * corresponding local datapath accordingly. */
+struct lport *vtep_lport;
+ovs_list_size(&vtep_lports);
+LIST_FOR_EACH_POP (vtep_lport, list_node, &vtep_lports) {
+update_ld_vtep_port(vtep_lport->pb, b_ctx_out->local_datapaths);
+free(vtep_lport);
+}
+
shash_destroy(&bridge_mappings);
/* Remove stale QoS entries. */
ovs_qos_entries_gc(b_ctx_in->ovs_idl_txn, b_ctx_in->ovsrec_port_by_qos,
@@ -2175,6 +2215,11 @@ remove_pb_from_local_datapath(const struct
sbrec_port_binding *pb,
}
} else if (!strcmp(pb->type, "external")) {
remove_local_datapath_external_port(ld, pb->logical_port);
+} else if (!strcmp(pb->
[ovs-dev] [PATCH ovn 3/5] controller: move put_load&resubmit for port-binding in function
This is done to simplify and remove duplication of code.
New function will be used in next patch.
Signed-off-by: Vladislav Odintsov
---
controller/physical.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/controller/physical.c b/controller/physical.c
index ec861f49c..2925dcd1d 100644
--- a/controller/physical.c
+++ b/controller/physical.c
@@ -1704,6 +1704,13 @@ chassis_is_vtep(const struct sbrec_chassis *chassis)
return smap_get_bool(&chassis->other_config, "is-vtep", false);
}
+static void
+local_output_pb(int64_t tunnel_key, struct ofpbuf *ofpacts)
+{
+put_load(tunnel_key, MFF_LOG_OUTPORT, 0, 32, ofpacts);
+put_resubmit(OFTABLE_CHECK_LOOPBACK, ofpacts);
+}
+
static void
consider_mc_group(struct ovsdb_idl_index *sbrec_port_binding_by_name,
enum mf_field_id mff_ovn_geneve,
@@ -1773,13 +1780,9 @@ consider_mc_group(struct ovsdb_idl_index
*sbrec_port_binding_by_name,
if (!strcmp(port->type, "patch")) {
if (ldp->is_transit_switch) {
-put_load(port->tunnel_key, MFF_LOG_OUTPORT, 0, 32,
- &ofpacts);
-put_resubmit(OFTABLE_CHECK_LOOPBACK, &ofpacts);
+local_output_pb(port->tunnel_key, &ofpacts);
} else {
-put_load(port->tunnel_key, MFF_LOG_OUTPORT, 0, 32,
- &remote_ofpacts);
-put_resubmit(OFTABLE_CHECK_LOOPBACK, &remote_ofpacts);
+local_output_pb(port->tunnel_key, &remote_ofpacts);
}
} if (!strcmp(port->type, "remote")) {
if (port->chassis) {
@@ -1790,18 +1793,14 @@ consider_mc_group(struct ovsdb_idl_index
*sbrec_port_binding_by_name,
port->tunnel_key, &remote_ofpacts);
}
} else if (!strcmp(port->type, "localport")) {
-put_load(port->tunnel_key, MFF_LOG_OUTPORT, 0, 32,
- &remote_ofpacts);
-put_resubmit(OFTABLE_CHECK_LOOPBACK, &remote_ofpacts);
+local_output_pb(port->tunnel_key, &remote_ofpacts);
} else if ((port->chassis == chassis
|| is_additional_chassis(port, chassis))
&& (local_binding_get_primary_pb(local_bindings, lport_name)
|| !strcmp(port->type, "l3gateway"))) {
-put_load(port->tunnel_key, MFF_LOG_OUTPORT, 0, 32, &ofpacts);
-put_resubmit(OFTABLE_CHECK_LOOPBACK, &ofpacts);
+local_output_pb(port->tunnel_key, &ofpacts);
} else if (simap_contains(patch_ofports, port->logical_port)) {
-put_load(port->tunnel_key, MFF_LOG_OUTPORT, 0, 32, &ofpacts);
-put_resubmit(OFTABLE_CHECK_LOOPBACK, &ofpacts);
+local_output_pb(port->tunnel_key, &ofpacts);
} else if (!strcmp(port->type, "chassisredirect")
&& port->chassis == chassis) {
const char *distributed_port = smap_get(&port->options,
@@ -1812,9 +1811,7 @@ consider_mc_group(struct ovsdb_idl_index
*sbrec_port_binding_by_name,
distributed_port);
if (distributed_binding
&& port->datapath == distributed_binding->datapath) {
-put_load(distributed_binding->tunnel_key, MFF_LOG_OUTPORT,
- 0, 32, &ofpacts);
-put_resubmit(OFTABLE_CHECK_LOOPBACK, &ofpacts);
+local_output_pb(distributed_binding->tunnel_key, &ofpacts);
}
}
} else if (!get_localnet_port(local_datapaths,
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 2/5] northd: build vtep hairpin lflows only for lswitches with vtep lports
There is no need to build lflows for datapaths, where there are no vtep type
lports. For instance, edge-outside logical switch, which has no vtep lports
but has many chassis redirect lport, can have many useless lflows.
Signed-off-by: Vladislav Odintsov
---
northd/northd.c | 5 +
northd/ovn-northd.8.xml | 15 +--
tests/ovn-northd.at | 3 ---
3 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index d6c26735d..e713973e7 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -7818,6 +7818,11 @@ build_lb_hairpin(struct ovn_datapath *od, struct hmap
*lflows)
static void
build_vtep_hairpin(struct ovn_datapath *od, struct hmap *lflows)
{
+if (!od->has_vtep_lports) {
+/* There is no need in these flows if datapath has no vtep lports. */
+return;
+}
+
/* Ingress Pre-ARP flows for VTEP hairpining traffic. Priority 1000:
* Packets that received from VTEP ports must go directly to L2LKP table.
*/
diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index a8ef00a28..8164be300 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -1143,9 +1143,10 @@
- For each distributed gateway router port RP attached to
- the logical switch and has chassis redirect port cr-RP, a
- priority-2000 flow is added with the match
+ If logical switch has attached logical switch port of vtep
+ type, then for each distributed gateway router port RP
+ attached to this logical switch and has chassis redirect port
+ cr-RP, a priority-2000 flow is added with the match
reg0[14] == 1 && is_chassis_resident(cr-RP)
@@ -1159,9 +1160,11 @@
-A priority-1000 flow that matches on reg0[14] register
-bit for the traffic received from HW VTEP (ramp) ports. This traffic
-is passed to ingress table ls_in_l2_lkup.
+If logical switch has attached logical switch port of vtep
+type, then a priority-1000 flow that matches on
+reg0[14] register bit for the traffic received from HW
+VTEP (ramp) ports. This traffic is passed to ingress table
+ls_in_l2_lkup.
A priority-1 flow that hairpins traffic matched by non-default
diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
index 2c4129bf3..5021b45f8 100644
--- a/tests/ovn-northd.at
+++ b/tests/ovn-northd.at
@@ -2961,7 +2961,6 @@ AT_CHECK([ovn-sbctl lflow-list sw0 | grep
ls_in_nat_hairpin | sort | sed 's/tabl
AT_CHECK([ovn-sbctl lflow-list sw0 | grep ls_in_hairpin | sort | sed
's/table=../table=??/g'], [0], [dnl
table=??(ls_in_hairpin ), priority=0, match=(1), action=(next;)
table=??(ls_in_hairpin ), priority=1, match=((reg0[[6]] == 1 ||
reg0[[12]] == 1)), action=(eth.dst <-> eth.src; outport = inport;
flags.loopback = 1; output;)
- table=??(ls_in_hairpin ), priority=1000 , match=(reg0[[14]] == 1),
action=(next(pipeline=ingress, table=??);)
])
check ovn-nbctl -- ls-lb-del sw0 lb0
@@ -2977,7 +2976,6 @@ AT_CHECK([ovn-sbctl lflow-list sw0 | grep
ls_in_nat_hairpin | sort | sed 's/tabl
AT_CHECK([ovn-sbctl lflow-list sw0 | grep ls_in_hairpin | sort | sed
's/table=../table=??/g'], [0], [dnl
table=??(ls_in_hairpin ), priority=0, match=(1), action=(next;)
- table=??(ls_in_hairpin ), priority=1000 , match=(reg0[[14]] == 1),
action=(next(pipeline=ingress, table=??);)
])
check ovn-nbctl -- add load_balancer_group $lbg load_balancer $lb0
@@ -2998,7 +2996,6 @@ AT_CHECK([ovn-sbctl lflow-list sw0 | grep
ls_in_nat_hairpin | sort | sed 's/tabl
AT_CHECK([ovn-sbctl lflow-list sw0 | grep ls_in_hairpin | sort | sed
's/table=../table=??/g'], [0], [dnl
table=??(ls_in_hairpin ), priority=0, match=(1), action=(next;)
table=??(ls_in_hairpin ), priority=1, match=((reg0[[6]] == 1 ||
reg0[[12]] == 1)), action=(eth.dst <-> eth.src; outport = inport;
flags.loopback = 1; output;)
- table=??(ls_in_hairpin ), priority=1000 , match=(reg0[[14]] == 1),
action=(next(pipeline=ingress, table=??);)
])
AT_CLEANUP
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 4/5] controller: fix typo in comments
Signed-off-by: Vladislav Odintsov --- controller/binding.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/controller/binding.c b/controller/binding.c index 28218b2e8..c7a2b3f10 100644 --- a/controller/binding.c +++ b/controller/binding.c @@ -2092,7 +2092,7 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct binding_ctx_out *b_ctx_out) free(lnet_lport); } -/* Run through external lport list to see if these are external ports +/* Run through external lport list to see if there are external ports * on local datapaths discovered from above loop, and update the * corresponding local datapath accordingly. */ struct lport *ext_lport; @@ -2101,7 +2101,7 @@ binding_run(struct binding_ctx_in *b_ctx_in, struct binding_ctx_out *b_ctx_out) free(ext_lport); } -/* Run through multichassis lport list to see if these are ports +/* Run through multichassis lport list to see if there are ports * on local datapaths discovered from above loop, and update the * corresponding local datapath accordingly. */ struct lport *multichassis_lport; -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 1/5] northd: fix ls_in_hairpin l3dgw flow generation
This patch fixes a situation, where logical flow with incorrect syntax could
be generated. If a logical switch has two attached logical router ports and
one of them has configured gateway chassis, then incorrect flow can have the
match like:
`reg0[14] == 1 && (is_chassis_resident("cr-lrp2") || ` or
`is_chassis_resident("cr-lrp1"))`
The flow's match was reworked to have at maximum one 'is_chassis_resident()'
part. For each cr-lport a new lflow is created. There should not be many
cr-lports within one datapath (normally there is just one), so the lflows
count shouldn't increase dramatically.
Now the match looks like:
`reg0[14] == 1 && is_chassis_resident("cr-lrp2")`
As an additional enhancement, the code became easier and tests were also
simplified.
Documentation and relevant testcases were updated.
Fixes: 4e90bcf55c2e ("controller, northd, vtep: support routed networks with HW
VTEP")
Signed-off-by: Vladislav Odintsov
---
northd/northd.c | 35 ++-
northd/ovn-northd.8.xml | 13 +++--
tests/ovn.at| 17 +++--
3 files changed, 24 insertions(+), 41 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index 07b127cdf..d6c26735d 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -7819,37 +7819,30 @@ static void
build_vtep_hairpin(struct ovn_datapath *od, struct hmap *lflows)
{
/* Ingress Pre-ARP flows for VTEP hairpining traffic. Priority 1000:
- * Packets that received from non-VTEP ports should continue processing. */
-
+ * Packets that received from VTEP ports must go directly to L2LKP table.
+ */
char *action = xasprintf("next(pipeline=ingress, table=%d);",
ovn_stage_get_table(S_SWITCH_IN_L2_LKUP));
-/* send all traffic from VTEP directly to L2LKP table. */
ovn_lflow_add(lflows, od, S_SWITCH_IN_HAIRPIN, 1000,
REGBIT_FROM_RAMP" == 1", action);
free(action);
-struct ds match = DS_EMPTY_INITIALIZER;
-size_t n_ports = od->n_router_ports;
-bool dp_has_l3dgw_ports = false;
-for (int i = 0; i < n_ports; i++) {
-if (is_l3dgw_port(od->router_ports[i]->peer)) {
-ds_put_format(&match, "%sis_chassis_resident(%s)%s",
- i == 0 ? REGBIT_FROM_RAMP" == 1 && (" : "",
- od->router_ports[i]->peer->cr_port->json_key,
- i < n_ports - 1 ? " || " : ")");
-dp_has_l3dgw_ports = true;
-}
-}
-
/* Ingress pre-arp flow for traffic from VTEP (ramp) switch.
* Priority 2000: Packets, that were received from VTEP (ramp) switch and
* router ports of current datapath are l3dgw ports and they reside on
* current chassis, should be passed to next table for ARP/ND hairpin
-* processing.
-*/
-if (dp_has_l3dgw_ports) {
-ovn_lflow_add(lflows, od, S_SWITCH_IN_HAIRPIN, 2000, ds_cstr(&match),
- "next;");
+* processing. */
+struct ds match = DS_EMPTY_INITIALIZER;
+for (int i = 0; i < od->n_router_ports; i++) {
+struct ovn_port *op = od->router_ports[i]->peer;
+if (is_l3dgw_port(op)) {
+ds_clear(&match);
+ds_put_format(&match,
+ REGBIT_FROM_RAMP" == 1 && is_chassis_resident(%s)",
+ op->cr_port->json_key);
+ovn_lflow_add(lflows, od, S_SWITCH_IN_HAIRPIN, 2000,
+ ds_cstr(&match), "next;");
+}
}
ds_destroy(&match);
}
diff --git a/northd/ovn-northd.8.xml b/northd/ovn-northd.8.xml
index 540fe03bd..a8ef00a28 100644
--- a/northd/ovn-northd.8.xml
+++ b/northd/ovn-northd.8.xml
@@ -1144,16 +1144,17 @@
For each distributed gateway router port RP attached to
- the logical switch, a priority-2000 flow is added with the match
- reg0[14] == 1 && is_chassis_resident(RP)
- and action next; to pass the traffic to the
- next table to respond to the ARP requests for the router port IPs.
+ the logical switch and has chassis redirect port cr-RP, a
+ priority-2000 flow is added with the match
+
+reg0[14] == 1 && is_chassis_resident(cr-RP)
+
+ and action next;.
reg0[14] register bit is set in the ingress L2 port
- security check table for traffic received from HW VTEP (ramp)
- ports.
+ security check table for traffic received from HW VTEP (ramp) ports.
diff --git a/tests/ovn.at b/tests/ovn.at
index 9e6e8a14a..53349530b 100644
--- a/tests/ovn.at
+++ b/tests/ovn.at
@@ -4432,24
[ovs-dev] [PATCH ovn 0/5] VTEP lport ARP handling fixes & GARP support
This patch series brings enhancements to ARP/ND traffic coming from vtep logical switch port. Patch #1 shoud be backported to old branches as it is a bugfix. Patch #2 makes a small optimisation - removed unneeded logical flows, it can be also backported. Patch #3 is a preparation for patch #5, which removes some code duplication. Patch #5 adds support for GARP coming from vtep lport handling on chassisredirect port and makes some changes in ARP/ND responder logic. Vladislav Odintsov (5): northd: fix ls_in_hairpin l3dgw flow generation northd: build vtep hairpin lflows only for lswitches with vtep lports controller: move put_load&resubmit for port-binding in function controller: fix typo in comments controller,northd: pass arp/nd from HW VTEP to lrouter pipeline controller/binding.c| 52 +- controller/local_data.h | 3 ++ controller/physical.c | 75 +++--- northd/northd.c | 50 + northd/ovn-northd.8.xml | 30 +++ tests/ovn-northd.at | 3 -- tests/ovn.at| 116 ++-- 7 files changed, 258 insertions(+), 71 deletions(-) -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [ovn] help wanted: how MC_FLOOD actions works for eth.mcast traffic coming from localnet lports?
Thanks Dumitru for the response.
I’ve looked through this code and even tried to implement similar logic for
vtep lport, but realized, that vtep mcast traffic is a bit different from
localnet port.
mcast traffic originated in normal vif port in localnet-attached lswitch has
two cases:
- if uplink bridge mapping is locally available, the mcast packet is sent to
this interface assuming classic network switch outside of ovn will flood it in
l2 domain
- if uplink bridge mapping is locally unawailable, such mcast packet is flooded
in overlay. (honestly I didn’t find code related to this logic, I’ve found it
just performing tests)
With same logic implemented in consider_mc_group() the BUM traffic originated
in vif lport doesn’t reach remote chassis at all…
With vtep lport mcast traffic must be replicated always on source node, but
it’s prohibited to re-send received from vtep lport mcast packets to other
remote chassis.
I guess I need to reject mcast l2 flood to remote ports if REGBIT_FROM_RAMP ==
1.
Do you have an idea for the correct place to put such logic in?
> On 16 May 2023, at 23:02, Dumitru Ceara wrote:
>
> On 5/16/23 21:48, Vladislav Odintsov wrote:
>> Hi Numan, Dumitru, Ilya, Mark,
>>
>
> Hi Vladislav,
>
>> if someone can help, I’ll be very grateful.
>>
>> Thanks in advance.
>>
>>> On 15 May 2023, at 15:06, Vladislav Odintsov wrote:
>>>
>>> Hi, I’m implementing neighbour learning on the chassis-redirect ports
>>> for traffic coming from lport of vtep type and have some
>>> misunderstanding of how MC_FLOOD action works with traffic coming from
>>> localnet lports. Imagine, we’ve got lswitch with 4 LSPs: - vtep lport
>>> (type vtep) - lrp (chassis-redirect configured router port on hv1) -
>>> lsp1 on hv1 - lsp2 on hv2 My problem is that mcast/bcast traffic
>>> coming from vtep lport got flooded to all logical ports of the
>>> lswitch, even for those which reside on another hypervisor (hv2 in
>>> this example), resulting in duplicated packets on lsp2 vif port. vtep
>>> switch performs source node replication of BUM traffic, so bcast
>>> packets reach normal vif lports + MC_FLOOD in ls_in_l2_lkup. I’m
>>> comparing behaviour with localnet port in same setup (lswitch with 2
>>> LSPs on different hypervisors) and see there is no such behaviour: packets
>>> don’t get flooded to vif lports on other chassis.
>>> I see that eth.mcast traffic is matched in ls_in_l2_lkup lflow table with
>>> the action 'outport = "_MC_flood"; output;', then it got flooded to only
>>> LRPs of LS and *local* vif lports. The question is - where is the
>>> logic, which prevents flooding from localnet to vif located on other
>>> chassis? Am I missing something? Let me know if any additional
>>> information is needed. Thanks!
>>>
>
> For localnet ports the key is in how ovn-controllers expand (L2)
> multicast_groups. In consider_mc_group() [0]:
>
>/* Go through all of the ports in the multicast group:
> *
> *- For remote ports, add the chassis to 'remote_chassis' or
> * 'vtep_chassis'.
> *
> *- For local ports (other than logical patch ports), add actions
> * to 'ofpacts' to set the output port and resubmit.
> *
> *- For logical patch ports, add actions to 'remote_ofpacts'
> * instead. (If we put them in 'ofpacts', then the output
> * would happen on every hypervisor in the multicast group,
> * effectively duplicating the packet.) The only exception
> * is in case of transit switches (used by OVN-IC). We need
> * patch ports to be processed on the remote side, after
> * crossing the AZ boundary.
> *
> *- For chassisredirect ports, add actions to 'ofpacts' to
> * set the output port to be the router patch port for which
> * the redirect port was added.
> */
>
> Later on, we have a special check for switches with localnet
> ports and we don't forward traffic to remote ports in that
> case because multicast traffic reaches remote ports through
> the localnet directly:
>
>} else if (!get_localnet_port(local_datapaths,
> mc->datapath->tunnel_key)) {
>/* Add remote chassis only when localnet port not exist,
> * otherwise multicast will reach remote ports through localnet
> * port. */
>if (port->chassis) {
>if (chassis_is_vtep(port->chassis)) {
>sset_add(&vtep_chassi
Re: [ovs-dev] [ovn] ha-chassis-group false positive failover
> On 16 May 2023, at 23:54, Numan Siddique wrote: > > Hi Vladislav, > > Sorry for the late reply. > > PSB for few comments. Thanks for your reply! My answers are inline. > > > > On Tue, May 16, 2023 at 3:42 PM Vladislav Odintsov <mailto:odiv...@gmail.com>> wrote: >> >> Hi Numan, Dumitru, Ilya, >> >> I guess I’ve managed to deal with some of these problems and have some >> conclusions. >> Please see inline. >> >>> On 14 Apr 2023, at 16:26, Vladislav Odintsov wrote: >>> >>> And as a follow-up, I see sometimes next error message in ovn-controller >>> log, though there is a configured much higher limit in seconds for >>> inactivity probe value for the chassis: >>> >> >> ovn-controller establishes 3 openflow connections to local ovs-vswitchd for >> next purposes: >> 1. openflow rules management (openflow probe interval is configured through >> ovn-openflow-probe-interval external_ids setting [1]; default — disabled >> [2]); >> 2. openflow features collection (hardcoded probe interval 5s [3]); >> 3. pinctrl thread (hardcoded probe interval 5s [4]). >> >>> ovs|04426|rconn|ERR|unix:/run/openvswitch/br-int.mgmt: no response to >>> inactivity probe after 8 seconds, disconnecting >>> >>> ovs|26560|rconn|ERR|unix:/run/openvswitch/br-int.mgmt: no response to >>> inactivity probe after 10 seconds, disconnecting >>> >> >> These messages most likely related to the connection for features collection >> or pinctrl thread. So ovn-openflow-probe-interval has no matter here. >> >>> >>> server with first log message: >>> # ovs-vsctl get open . external_ids:ovn-openflow-probe-interval >>> "30" >>> >>> server with second log message: >>> # ovs-vsctl get open . external_ids:ovn-openflow-probe-interval >>> "60" >>> >>> >>> >>>> On 30 Mar 2023, at 23:19, Vladislav Odintsov wrote: >>>> >>>> Hi all, >>>> >>>> I’m facing a false positive failover in the event of openflow connection >>>> got dropped after inactivity probe timeout due to high load of >>>> ovn-controller handling huge amount of ovsdb updates. >>>> I wonder wether its a bug or I have to tune any specifics. See >>>> ovn-controller logs: >>>> >>>> 2023-03-30T07:57:24.469Z|58440|inc_proc_eng|INFO|node: >>>> logical_flow_output, recompute (failed handler for input port_groups) took >>>> 35774ms >>>> 2023-03-30T07:57:28.521Z|58441|lflow_cache|INFO|Detected cache inactivity >>>> (last active 40006 ms ago): trimming cache >>>> 2023-03-30T07:57:28.528Z|58442|timeval|WARN|Unreasonably long 40084ms poll >>>> interval (32947ms user, 6968ms system) >>>> 2023-03-30T07:57:28.528Z|58443|timeval|WARN|faults: 43468 minor, 0 major >>>> ….. >>>> 2023-03-30T07:57:48.784Z|58496|reconnect|ERR|ssl::6642: no response to >>>> inactivity probe after 60.2 seconds, disconnecting >>>> 2023-03-30T07:57:48.784Z|58497|reconnect|INFO|ssl::6642: connection >>>> dropped >>>> 2023-03-30T07:57:48.905Z|58498|main|INFO|OVNSB commit failed, force >>>> recompute next time. >>>> 2023-03-30T07:57:49.786Z|58499|reconnect|INFO|ssl::6642: connecting... >>>> 2023-03-30T07:57:49.924Z|58500|reconnect|INFO|ssl::6642: connected >>>> 2023-03-30T07:57:29.781Z|58501|poll_loop|INFO|wakeup due to 0-ms timeout >>>> at lib/stream-ssl.c:838 (74% CPU usage) >>>> 2023-03-30T07:57:29.836Z|58502|poll_loop|INFO|wakeup due to 0-ms timeout >>>> at lib/stream-ssl.c:838 (74% CPU usage) >>>> …. >>>> 2023-03-30T07:57:05.976Z|58545|poll_loop|INFO|wakeup due to 0-ms timeout >>>> at lib/stream-ssl.c:838 (101% CPU usage) >>>> 2023-03-30T07:57:07.002Z|58546|memory|INFO|peak resident set size grew 54% >>>> in last 682257.2 seconds, from 4435696 kB to 6824820 kB >>>> 2023-03-30T07:57:07.002Z|58547|memory|INFO|idl-cells-OVN_Southbound:11491359 >>>> idl-cells-Open_vSwitch:14416 lflow-cache-entries-cache-expr:530298 >>>> lflow-cache-entries-cache-matches:31770 lflow-cache-size-KB:769553 >>>> local_datapath_usage-KB:630 >>>> ofctrl_desired_flow_usage-KB:577052 ofctrl_installed_flow_usage-KB:409538 >>>> ofctrl_sb_flow_ref_usage-KB:273707 >>>> … >>>> 2023-03-30T07:57:31.667Z|58
Re: [ovs-dev] [ovn] help wanted: how MC_FLOOD actions works for eth.mcast traffic coming from localnet lports?
Hi Numan, Dumitru, Ilya, Mark, if someone can help, I’ll be very grateful. Thanks in advance. > On 15 May 2023, at 15:06, Vladislav Odintsov wrote: > > Hi, > > I’m implementing neighbour learning on the chassis-redirect ports for > traffic coming from lport of vtep type and have some misunderstanding of > how MC_FLOOD action works with traffic coming from localnet lports. > > Imagine, we’ve got lswitch with 4 LSPs: > - vtep lport (type vtep) > - lrp (chassis-redirect configured router port on hv1) > - lsp1 on hv1 > - lsp2 on hv2 > > My problem is that mcast/bcast traffic coming from vtep lport got flooded > to all logical ports of the lswitch, even for those which reside on > another hypervisor (hv2 in this example), resulting in duplicated packets > on lsp2 vif port. vtep switch performs source node replication of BUM > traffic, so bcast packets reach normal vif lports + MC_FLOOD in > ls_in_l2_lkup. > > I’m comparing behaviour with localnet port in same setup (lswitch with 2 > LSPs on different hypervisors) and see there is no such behaviour: packets > don’t get flooded to vif lports on other chassis. > I see that eth.mcast traffic is matched in ls_in_l2_lkup lflow table with > the action 'outport = "_MC_flood"; output;', then it got flooded to only > LRPs of LS and *local* vif lports. > The question is - where is the logic, which prevents flooding from > localnet to vif located on other chassis? Am I missing something? > > Let me know if any additional information is needed. > > Thanks! > > Regards, > Vladislav Odintsov > Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [ovn] ha-chassis-group false positive failover
Hi Numan, Dumitru, Ilya, I guess I’ve managed to deal with some of these problems and have some conclusions. Please see inline. > On 14 Apr 2023, at 16:26, Vladislav Odintsov wrote: > > And as a follow-up, I see sometimes next error message in ovn-controller log, > though there is a configured much higher limit in seconds for inactivity > probe value for the chassis: > ovn-controller establishes 3 openflow connections to local ovs-vswitchd for next purposes: 1. openflow rules management (openflow probe interval is configured through ovn-openflow-probe-interval external_ids setting [1]; default — disabled [2]); 2. openflow features collection (hardcoded probe interval 5s [3]); 3. pinctrl thread (hardcoded probe interval 5s [4]). > ovs|04426|rconn|ERR|unix:/run/openvswitch/br-int.mgmt: no response to > inactivity probe after 8 seconds, disconnecting > > ovs|26560|rconn|ERR|unix:/run/openvswitch/br-int.mgmt: no response to > inactivity probe after 10 seconds, disconnecting > These messages most likely related to the connection for features collection or pinctrl thread. So ovn-openflow-probe-interval has no matter here. > > server with first log message: > # ovs-vsctl get open . external_ids:ovn-openflow-probe-interval > "30" > > server with second log message: > # ovs-vsctl get open . external_ids:ovn-openflow-probe-interval > "60" > > > >> On 30 Mar 2023, at 23:19, Vladislav Odintsov wrote: >> >> Hi all, >> >> I’m facing a false positive failover in the event of openflow connection got >> dropped after inactivity probe timeout due to high load of ovn-controller >> handling huge amount of ovsdb updates. >> I wonder wether its a bug or I have to tune any specifics. See >> ovn-controller logs: >> >> 2023-03-30T07:57:24.469Z|58440|inc_proc_eng|INFO|node: logical_flow_output, >> recompute (failed handler for input port_groups) took 35774ms >> 2023-03-30T07:57:28.521Z|58441|lflow_cache|INFO|Detected cache inactivity >> (last active 40006 ms ago): trimming cache >> 2023-03-30T07:57:28.528Z|58442|timeval|WARN|Unreasonably long 40084ms poll >> interval (32947ms user, 6968ms system) >> 2023-03-30T07:57:28.528Z|58443|timeval|WARN|faults: 43468 minor, 0 major >> ….. >> 2023-03-30T07:57:48.784Z|58496|reconnect|ERR|ssl::6642: no response to >> inactivity probe after 60.2 seconds, disconnecting >> 2023-03-30T07:57:48.784Z|58497|reconnect|INFO|ssl::6642: connection >> dropped >> 2023-03-30T07:57:48.905Z|58498|main|INFO|OVNSB commit failed, force >> recompute next time. >> 2023-03-30T07:57:49.786Z|58499|reconnect|INFO|ssl::6642: connecting... >> 2023-03-30T07:57:49.924Z|58500|reconnect|INFO|ssl::6642: connected >> 2023-03-30T07:57:29.781Z|58501|poll_loop|INFO|wakeup due to 0-ms timeout at >> lib/stream-ssl.c:838 (74% CPU usage) >> 2023-03-30T07:57:29.836Z|58502|poll_loop|INFO|wakeup due to 0-ms timeout at >> lib/stream-ssl.c:838 (74% CPU usage) >> …. >> 2023-03-30T07:57:05.976Z|58545|poll_loop|INFO|wakeup due to 0-ms timeout at >> lib/stream-ssl.c:838 (101% CPU usage) >> 2023-03-30T07:57:07.002Z|58546|memory|INFO|peak resident set size grew 54% >> in last 682257.2 seconds, from 4435696 kB to 6824820 kB >> 2023-03-30T07:57:07.002Z|58547|memory|INFO|idl-cells-OVN_Southbound:11491359 >> idl-cells-Open_vSwitch:14416 lflow-cache-entries-cache-expr:530298 >> lflow-cache-entries-cache-matches:31770 lflow-cache-size-KB:769553 >> local_datapath_usage-KB:630 >> ofctrl_desired_flow_usage-KB:577052 ofctrl_installed_flow_usage-KB:409538 >> ofctrl_sb_flow_ref_usage-KB:273707 >> … >> 2023-03-30T07:57:31.667Z|58552|rconn|WARN|unix:/run/openvswitch/br-int.mgmt: >> connection dropped (Broken pipe) >> 2023-03-30T07:57:31.739Z|58553|binding|INFO|Releasing lport cr-xxx from this >> chassis (sb_readonly=0) >> 2023-03-30T07:57:31.739Z|58554|if_status|WARN|Dropped 1 log messages in last >> 1254725 seconds (most recently, 1254725 seconds ago) due to excessive rate >> 2023-03-30T07:57:31.739Z|58555|if_status|WARN|Trying to release unknown >> interface cr-xxx >> 2023-03-30T07:57:31.743Z|58556|binding|INFO|Releasing lport cr-yyy from this >> chassis (sb_readonly=0) >> 2023-03-30T07:57:31.743Z|58557|binding|INFO|Releasing lport cr-zzz from this >> chassis (sb_readonly=0) >> … >> >> After some time these ports are claimed back: >> >> 2023-03-30T07:57:49.320Z|59137|rconn|INFO|unix:/run/openvswitch/br-int.mgmt: >> connecting... >> 2023-03-30T07:57:49.320Z|59138|rconn|INFO|unix:/run/openvswitch/br-int.mgmt: >> connected >>
[ovs-dev] [ovn] help wanted: how MC_FLOOD actions works for eth.mcast traffic coming from localnet lports?
Hi, I’m implementing neighbour learning on the chassis-redirect ports for traffic coming from lport of vtep type and have some misunderstanding of how MC_FLOOD action works with traffic coming from localnet lports. Imagine, we’ve got lswitch with 4 LSPs: - vtep lport (type vtep) - lrp (chassis-redirect configured router port on hv1) - lsp1 on hv1 - lsp2 on hv2 My problem is that mcast/bcast traffic coming from vtep lport got flooded to all logical ports of the lswitch, even for those which reside on another hypervisor (hv2 in this example), resulting in duplicated packets on lsp2 vif port. vtep switch performs source node replication of BUM traffic, so bcast packets reach normal vif lports + MC_FLOOD in ls_in_l2_lkup. I’m comparing behaviour with localnet port in same setup (lswitch with 2 LSPs on different hypervisors) and see there is no such behaviour: packets don’t get flooded to vif lports on other chassis. I see that eth.mcast traffic is matched in ls_in_l2_lkup lflow table with the action 'outport = "_MC_flood"; output;', then it got flooded to only LRPs of LS and *local* vif lports. The question is - where is the logic, which prevents flooding from localnet to vif located on other chassis? Am I missing something? Let me know if any additional information is needed. Thanks! Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn] ovn-controller docs: fix typo in ovn-monitor-all description
Make it more clear that ovn-monitor-all option has effect on OVN Southbound database rather than local OVS. Reported-at: https://mail.openvswitch.org/pipermail/ovs-discuss/2023-May/052421.html Reported-by: Ilya Maximets Signed-off-by: Vladislav Odintsov --- controller/ovn-controller.8.xml | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/controller/ovn-controller.8.xml b/controller/ovn-controller.8.xml index ab52e2d34..7c0855603 100644 --- a/controller/ovn-controller.8.xml +++ b/controller/ovn-controller.8.xml @@ -121,11 +121,11 @@ that is needed in the current chassis. - It is more optimal to set it to true in use cases when - the chassis would anyway need to monitor most of the records in - ovs-database, which would save the overhead of conditions - processing, especially for server side. Typically, set it to - true for environments that all workloads need to be + It is more efficient to set it to true in use cases + where the chassis would anyway need to monitor most of the records in + OVN Southbound database, which would save the overhead of + conditions processing, especially for server side. Typically, set it + to true for environments that all workloads need to be reachable from each other. -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v2] utilities: increase OVSDB inactivity probe interval for ovn-*ctl
Hi Dumitru, Mark, The new version (v4) has been submitted at https://patchwork.ozlabs.org/project/ovn/patch/20230504165510.4026066-1-odiv...@gmail.com/ > On 3 May 2023, at 17:18, Dumitru Ceara wrote: > > On 5/3/23 16:12, Vladislav Odintsov wrote: >> Hi Dumitru and Mark, >> >> thanks for the review! >> >>> On 3 May 2023, at 16:56, Dumitru Ceara wrote: >>> >>> On 5/3/23 15:47, Mark Michelson wrote: >>>> On 5/3/23 09:03, Dumitru Ceara wrote: >>>>> Hi Vladislav, >>>>> >>>>> On 5/3/23 02:55, Vladislav Odintsov wrote: >>>>>> For large OVN_Southbound (or other) databases the default interval of >>>>>> 5000 ms >>>>>> could be not sufficient to run. This patch adds configuration of OVSDB >>>>>> inactivity probes for ovn-*ctl utilities. >>>>>> >>>>>> Initially, on the utility start the hardcoded value of 12 ms is set. >>>>>> For daemon-mode it is possible to configure intervals in OVN Northbound >>>>>> database: >>>>>> OVN_Northbound.NB_Global.options.dbctl_inactivity_probe for ovn-nbctl >>>>>> and >>>>>> ovn-sbctl utilities. >>>>>> >>>>>> If no DB configuration option was provided, the initial (12 ms) >>>>>> interval >>>>>> is left. >>>>> >>>>> Nit: I would add here something like "A non-zero inactivity probe >>>>> interval is required in order to allow DB clients to detect connection >>>>> failures due to network issues." >>>>> >>>>>> >>>>>> Signed-off-by: Vladislav Odintsov >>>>>> --- >>>>>> lib/ovn-util.h | 2 ++ >>>>>> ovn-nb.xml | 20 >>>>>> utilities/ovn-dbctl.c| 18 ++ >>>>>> utilities/ovn-dbctl.h| 1 + >>>>>> utilities/ovn-ic-nbctl.c | 4 >>>>>> utilities/ovn-ic-sbctl.c | 4 >>>>>> utilities/ovn-nbctl.c| 15 +++ >>>>>> utilities/ovn-sbctl.c| 15 +++ >>>>> >>>>> I'm not sure whether we should we mention this user visible change in >>>>> the NEWS file. >>>> >>>> I think it's worth mentioning in the NEWS file. >>>> >>>>> >>>>>> 8 files changed, 79 insertions(+) >>>>>> >>>>>> diff --git a/lib/ovn-util.h b/lib/ovn-util.h >>>>>> index 7cf861dbc..47e53ca74 100644 >>>>>> --- a/lib/ovn-util.h >>>>>> +++ b/lib/ovn-util.h >>>>>> @@ -154,6 +154,8 @@ void set_idl_probe_interval(struct ovsdb_idl >>>>>> *idl, const char *remote, >>>>>> #define OVN_MAX_DP_VXLAN_KEY ((1u << 12) - 1) >>>>>> #define OVN_MAX_DP_VXLAN_KEY_LOCAL (OVN_MAX_DP_KEY - >>>>>> OVN_MAX_DP_GLOBAL_NUM) >>>>>> +#define DEFAULT_UTILS_PROBE_INTERVAL_MSEC 12 >>>>> >>>>> I think this should go to ovn-dbctl.h instead but whoever applies the >>>>> patch can move this. So I don't think there's a need for v3, therefore: >>>> >>>> I also agree with this suggestion. >> >> I’m also fine with this change and have no objection to fix this on the >> apply time if needed. >> >>>> >>>>> >>>>> Acked-by: Dumitru Ceara >>>>> >>>>> Ilya, Mark, Numan, Han, what do you guys think? >>>> >>>> Before I can ack this patch, I want to bring up two points: >>>> >>>> 1) This patch updates ovn-nb.xml, but it does not update ovn-sb.xml to >>>> document the new SB option. >>>> >>> >>> We already don't document everything that applies to both. >>> >>>> 2) I'm not a big fan of the name "dbctl_probe_interval", because the >>>> term "dbctl" is not well-known to most OVN users. My suggestion would be >>>> to call the NB option "nbctl_probe_interval" or >>>> "ovn_nbctl_probe_interval" and to call the SB option >>>> "sbctl_probe_interval" or "ovn_sbctl_probe_interval". This makes it more >>>> clear that the option pertains to the "ovn-nb
[ovs-dev] [PATCH ovn v4] utilities: increase OVSDB inactivity probe interval for ovn-*ctl
For large OVN_Southbound (or other) databases the default interval of 5000 ms
could be not sufficient to run. This patch adds configuration of OVSDB
inactivity probes for ovn-*ctl utilities.
Initially, on the utility start the hardcoded value of 12 ms is set.
For daemon-mode it is possible to configure intervals in OVN Northbound and
OVN Southbound databases for ovn-nbctl and ovn-sbctl utilities respectively.
Use
OVN_Northbound.NB_Global.options.nbctl_probe_interval for ovn-nbctl and
OVN_Southbound.SB_Global.options.sbctl_probe_interval for ovn-sbctl
utilities.
If no DB configuration option was provided, the initial (12 ms) interval
is left.
Signed-off-by: Vladislav Odintsov
---
v3 -> v4:
- Rebased on a fresh main branch.
v2 -> v3:
- Addressed Dumitru's and Mark's suggestion to split ovn-{n,s}bctl
configuration option dbctl_probe_interval for nbctl_... and sbctl_... .
- Added NEWS entry.
- Fixes typos.
- Added ovn-sb man entry for new option.
- Moved constant from ovn-util.h to ovn-dbctl.h.
---
NEWS | 7 +++
northd/northd.c | 9 +
ovn-nb.xml | 18 ++
ovn-sb.xml | 25 +
utilities/ovn-dbctl.c| 14 ++
utilities/ovn-dbctl.h| 3 +++
utilities/ovn-ic-nbctl.c | 5 +
utilities/ovn-ic-sbctl.c | 5 +
utilities/ovn-nbctl.c| 15 +++
utilities/ovn-sbctl.c| 15 +++
10 files changed, 116 insertions(+)
diff --git a/NEWS b/NEWS
index 60467581a..54303f834 100644
--- a/NEWS
+++ b/NEWS
@@ -14,6 +14,13 @@ Post v23.03.0
existing behaviour of flooding these arp requests to all attached Ports.
- Always allow IPv6 Router Discovery, Neighbor Discovery, and Multicast
Listener Discovery protocols, regardless of ACLs defined.
+ - Increased ovn-{ic-,}{n,s}bctl default OVSDB inactivity probe interval from
+5000 ms to 12 ms to give the ability to connect to large databases
+(mainly, OVN_Southbound). Also, for daemon mode it is possible to
+configure inactivity probe interval via OVN_Northbound and OVN_Southbound
+databases for ovn-nbctl and ovn-sbctl respectively. See man ovn-nb and
+man ovn-sb for 'nbctl_probe_interval' and 'sbctl_probe_interval'
+options for more details.
OVN v23.03.0 - 03 Mar 2023
--
diff --git a/northd/northd.c b/northd/northd.c
index b58f11633..eca1e6068 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -16715,6 +16715,15 @@ ovnnb_db_run(struct northd_input *input_data,
} else {
smap_remove(&options, "lb_hairpin_use_ct_mark");
}
+
+/* Hackaround SB_global.options overwrite by NB_Global.options for
+ * 'sbctl_probe_interval' option.
+ */
+const char *sip = smap_get(&sb->options, "sbctl_probe_interval");
+if (sip) {
+smap_replace(&options, "sbctl_probe_interval", sip);
+}
+
if (!smap_equal(&sb->options, &options)) {
sbrec_sb_global_set_options(sb, &options);
}
diff --git a/ovn-nb.xml b/ovn-nb.xml
index 0552eff19..0c1954792 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -215,6 +215,24 @@
+
+
+ The inactivity probe interval of the connection to the OVN Northbound
+ database from ovn-nbctl utility, in milliseconds.
+ If the value is zero, it disables the connection keepalive feature.
+
+
+
+ If the value is nonzero, then it will be forced to a value of
+ at least 1000 ms.
+
+
+
+ If the value is less than zero, then the default inactivity probe
+ interval for ovn-nbctl would be left intact (12 ms).
+
+
+
When used, this configuration value specifies the time, in
diff --git a/ovn-sb.xml b/ovn-sb.xml
index a77f8f4ef..aa78383d9 100644
--- a/ovn-sb.xml
+++ b/ovn-sb.xml
@@ -248,6 +248,31 @@
+
+
+ These options apply when ovn-sbctl connects to
+ OVN Southbound database.
+
+
+
+
+The inactivity probe interval of the connection to the OVN
+Southbound database from ovn-sbctl utility, in
+milliseconds. If the value is zero, it disables the connection
+keepalive feature.
+
+
+
+If the value is nonzero, then it will be forced to a value of
+at least 1000 ms.
+
+
+
+If the value is less than zero, then the default inactivity probe
+interval for ovn-sbctl would be left intact (12
ms).
+
+
+
diff --git a/utilities/ovn-dbctl.c b/utilities/ovn-dbctl.c
index 369a6a663..1d41157df 100644
--- a/utilities/ovn-dbctl.c
+++ b/utilities/ovn-dbctl.c
[ovs-dev] [PATCH ovn v3] utilities: increase OVSDB inactivity probe interval for ovn-*ctl
For large OVN_Southbound (or other) databases the default interval of 5000 ms
could be not sufficient to run. This patch adds configuration of OVSDB
inactivity probes for ovn-*ctl utilities.
Initially, on the utility start the hardcoded value of 12 ms is set.
For daemon-mode it is possible to configure intervals in OVN Northbound and
OVN Southbound databases for ovn-nbctl and ovn-sbctl utilities respectively.
Use
OVN_Northbound.NB_Global.options.nbctl_probe_interval for ovn-nbctl and
OVN_Southbound.SB_Global.options.sbctl_probe_interval for ovn-sbctl
utilities.
If no DB configuration option was provided, the initial (12 ms) interval
is left.
Signed-off-by: Vladislav Odintsov
---
v2 -> v3:
- Addressed Dumitru's and Mark's suggestion to split ovn-{n,s}bctl
configuration option dbctl_probe_interval for nbctl_... and sbctl_... .
- Added NEWS entry.
- Fixes typos.
- Added ovn-sb man entry for new option.
- Moved constant from ovn-util.h to ovn-dbctl.h.
---
NEWS | 7 +++
northd/northd.c | 9 +
ovn-nb.xml | 18 ++
ovn-sb.xml | 25 +
utilities/ovn-dbctl.c| 14 ++
utilities/ovn-dbctl.h| 3 +++
utilities/ovn-ic-nbctl.c | 5 +
utilities/ovn-ic-sbctl.c | 5 +
utilities/ovn-nbctl.c| 15 +++
utilities/ovn-sbctl.c| 15 +++
10 files changed, 116 insertions(+)
diff --git a/NEWS b/NEWS
index fc1b68324..8ae32a81e 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,13 @@ Post v23.03.0
addresses and CIDRs.
- Add support to configure OVSDB inactivity probe interval for ovn-ic and
ovn-controller-vtep.
+ - Increased ovn-{ic-,}{n,s}bctl default OVSDB inactivity probe interval from
+5000 ms to 12 ms to give the ability to connect to large databases
+(mainly, OVN_Southbound). Also, for daemon mode it is possible to
+configure inactivity probe interval via OVN_Northbound and OVN_Southbound
+databases for ovn-nbctl and ovn-sbctl respectively. See man ovn-nb and
+man ovn-sb for 'nbctl_probe_interval' and 'sbctl_probe_interval'
+options for more details.
OVN v23.03.0 - 03 Mar 2023
--
diff --git a/northd/northd.c b/northd/northd.c
index 5f0b436c2..a22ca1c71 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -16259,6 +16259,15 @@ ovnnb_db_run(struct northd_input *input_data,
} else {
smap_remove(&options, "lb_hairpin_use_ct_mark");
}
+
+/* Hackaround SB_global.options overwrite by NB_Global.options for
+ * 'sbctl_probe_interval' option.
+ */
+const char *sip = smap_get(&sb->options, "sbctl_probe_interval");
+if (sip) {
+smap_replace(&options, "sbctl_probe_interval", sip);
+}
+
if (!smap_equal(&sb->options, &options)) {
sbrec_sb_global_set_options(sb, &options);
}
diff --git a/ovn-nb.xml b/ovn-nb.xml
index fd32070f2..ee0aa5372 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -215,6 +215,24 @@
+
+
+ The inactivity probe interval of the connection to the OVN Northbound
+ database from ovn-nbctl utility, in milliseconds.
+ If the value is zero, it disables the connection keepalive feature.
+
+
+
+ If the value is nonzero, then it will be forced to a value of
+ at least 1000 ms.
+
+
+
+ If the value is less than zero, then the default inactivity probe
+ interval for ovn-nbctl would be left intact (12 ms).
+
+
+
When used, this configuration value specifies the time, in
diff --git a/ovn-sb.xml b/ovn-sb.xml
index a77f8f4ef..aa78383d9 100644
--- a/ovn-sb.xml
+++ b/ovn-sb.xml
@@ -248,6 +248,31 @@
+
+
+ These options apply when ovn-sbctl connects to
+ OVN Southbound database.
+
+
+
+
+The inactivity probe interval of the connection to the OVN
+Southbound database from ovn-sbctl utility, in
+milliseconds. If the value is zero, it disables the connection
+keepalive feature.
+
+
+
+If the value is nonzero, then it will be forced to a value of
+at least 1000 ms.
+
+
+
+If the value is less than zero, then the default inactivity probe
+interval for ovn-sbctl would be left intact (12
ms).
+
+
+
diff --git a/utilities/ovn-dbctl.c b/utilities/ovn-dbctl.c
index 369a6a663..1d41157df 100644
--- a/utilities/ovn-dbctl.c
+++ b/utilities/ovn-dbctl.c
@@ -205,6 +205,9 @@ ovn_dbctl_main(int argc, char *argv[],
ovsdb_idl_set_remote(idl, db, daemon_mode);
ovsdb_idl_set_leader_only(
Re: [ovs-dev] [PATCH ovn v2] utilities: increase OVSDB inactivity probe interval for ovn-*ctl
Hi Dumitru and Mark, thanks for the review! > On 3 May 2023, at 16:56, Dumitru Ceara wrote: > > On 5/3/23 15:47, Mark Michelson wrote: >> On 5/3/23 09:03, Dumitru Ceara wrote: >>> Hi Vladislav, >>> >>> On 5/3/23 02:55, Vladislav Odintsov wrote: >>>> For large OVN_Southbound (or other) databases the default interval of >>>> 5000 ms >>>> could be not sufficient to run. This patch adds configuration of OVSDB >>>> inactivity probes for ovn-*ctl utilities. >>>> >>>> Initially, on the utility start the hardcoded value of 12 ms is set. >>>> For daemon-mode it is possible to configure intervals in OVN Northbound >>>> database: >>>> OVN_Northbound.NB_Global.options.dbctl_inactivity_probe for ovn-nbctl >>>> and >>>> ovn-sbctl utilities. >>>> >>>> If no DB configuration option was provided, the initial (12 ms) >>>> interval >>>> is left. >>> >>> Nit: I would add here something like "A non-zero inactivity probe >>> interval is required in order to allow DB clients to detect connection >>> failures due to network issues." >>> >>>> >>>> Signed-off-by: Vladislav Odintsov >>>> --- >>>> lib/ovn-util.h | 2 ++ >>>> ovn-nb.xml | 20 >>>> utilities/ovn-dbctl.c| 18 ++ >>>> utilities/ovn-dbctl.h| 1 + >>>> utilities/ovn-ic-nbctl.c | 4 >>>> utilities/ovn-ic-sbctl.c | 4 >>>> utilities/ovn-nbctl.c| 15 +++ >>>> utilities/ovn-sbctl.c| 15 +++ >>> >>> I'm not sure whether we should we mention this user visible change in >>> the NEWS file. >> >> I think it's worth mentioning in the NEWS file. >> >>> >>>> 8 files changed, 79 insertions(+) >>>> >>>> diff --git a/lib/ovn-util.h b/lib/ovn-util.h >>>> index 7cf861dbc..47e53ca74 100644 >>>> --- a/lib/ovn-util.h >>>> +++ b/lib/ovn-util.h >>>> @@ -154,6 +154,8 @@ void set_idl_probe_interval(struct ovsdb_idl >>>> *idl, const char *remote, >>>> #define OVN_MAX_DP_VXLAN_KEY ((1u << 12) - 1) >>>> #define OVN_MAX_DP_VXLAN_KEY_LOCAL (OVN_MAX_DP_KEY - >>>> OVN_MAX_DP_GLOBAL_NUM) >>>> +#define DEFAULT_UTILS_PROBE_INTERVAL_MSEC 12 >>> >>> I think this should go to ovn-dbctl.h instead but whoever applies the >>> patch can move this. So I don't think there's a need for v3, therefore: >> >> I also agree with this suggestion. I’m also fine with this change and have no objection to fix this on the apply time if needed. >> >>> >>> Acked-by: Dumitru Ceara >>> >>> Ilya, Mark, Numan, Han, what do you guys think? >> >> Before I can ack this patch, I want to bring up two points: >> >> 1) This patch updates ovn-nb.xml, but it does not update ovn-sb.xml to >> document the new SB option. >> > > We already don't document everything that applies to both. > >> 2) I'm not a big fan of the name "dbctl_probe_interval", because the >> term "dbctl" is not well-known to most OVN users. My suggestion would be >> to call the NB option "nbctl_probe_interval" or >> "ovn_nbctl_probe_interval" and to call the SB option >> "sbctl_probe_interval" or "ovn_sbctl_probe_interval". This makes it more >> clear that the option pertains to the "ovn-nbctl" and "ovn-sbctl" >> utilities. However, if others disagree with me on this, then we can use >> "dbctl_probe_interval" . >> > > The problem is northd propagates all NB.NB_Global.options to > SB.SB_Global.options. Yes, this is due to the facts of northd logic for propagation options from NB_Global to SB_Global table. > >> I also have a couple of small findings below. >> >>> >>> Regards, >>> Dumitru >>> >>>> + >>>> struct hmap; >>>> void ovn_destroy_tnlids(struct hmap *tnlids); >>>> bool ovn_add_tnlid(struct hmap *set, uint32_t tnlid); >>>> diff --git a/ovn-nb.xml b/ovn-nb.xml >>>> index fd32070f2..a82f31a92 100644 >>>> --- a/ovn-nb.xml >>>> +++ b/ovn-nb.xml >>>> @@ -215,6 +215,26 @@ >>>> >>>>
Re: [ovs-dev] [PATCH ovn] utilities: disable OVSDB inactivity probes for non-daemon ovn-nbctl
Hi Dumitru, I’m a bit concerned about our last conversation’s idea how to set inactivity probe. The point is that in general case dbctl module can be used by multiple existing and possible future ovn-*ctl utilities. So, to configure a basic (we may call it a "startup" idl inactivity probe), which is hardcoded, let’s say to 12 ms, we should do this inside dbctl.c file. But if we’re talking about to read the contents of DB and try to find inactivity probe configuration there - such code must be in particular utility: ovn-sbctl/ovn-nbctl/etc, right? And it seems to me that the second configuration attempt of inactivity probe makes sense only in case of daemon-mode. So it’s needed after initial load of DB contents to read appropriate DB and reconfigure interval. I’ve posted v2 [1], please take a look on it. Let me know if you have any thoughts/concern. 1: https://patchwork.ozlabs.org/project/ovn/patch/20230503005531.4005891-1-odiv...@gmail.com/ > On 18 Apr 2023, at 18:31, Vladislav Odintsov wrote: > > > >> On 18 Apr 2023, at 16:59, Dumitru Ceara wrote: >> >> On 4/14/23 15:37, Vladislav Odintsov wrote: >>> Hi Dumitru, >>> >>>> On 13 Apr 2023, at 11:55, Dumitru Ceara wrote: >>>> >>>> Hi Vladislav, >>>> >>>> On 4/3/23 12:08, Ilya Maximets wrote: >>>>> On 3/31/23 17:17, Dumitru Ceara wrote: >>>>>> On 3/31/23 16:51, Vladislav Odintsov wrote: >>>>>>> As I understood from Ilya, in case of one-command run of ovn-sbctl >>>>>>> (non-daemon mode), it doesn’t make sense to have client -> server >>>>>>> inactivity probes. If cable is unplugged, will just hit tcp session >>>>>>> timeout, IIUC. >>>>>>> Please correct me if I’m wrong. >>>>>>> >>>>>> >>>>>> You're right but the default timeouts are quite large for TCP sessions: >>>>>> >>>>>> With keepalives default: >>>>>> tcp_keepalive_time - INTEGER >>>>>> How often TCP sends out keepalive messages when keepalive is enabled. >>>>>> Default: 2hours. >>>>>> >>>>>> tcp_keepalive_probes - INTEGER >>>>>> How many keepalive probes TCP sends out, until it decides that the >>>>>> connection is broken. Default value: 9. >>>>>> >>>>>> tcp_keepalive_intvl - INTEGER >>>>>> How frequently the probes are send out. Multiplied by >>>>>> tcp_keepalive_probes it is time to kill not responding connection, >>>>>> after probes started. Default value: 75sec i.e. connection >>>>>> will be aborted after ~11 minutes of retries. >>>>>> >>>>>> DB clients don't even enable tcp keepalives IIRC. >>>>>> >>>>>> So then we depend retransmits timing out: >>>>>> tcp_retries2 - INTEGER >>>>>> This value influences the timeout of an alive TCP connection, >>>>>> when RTO retransmissions remain unacknowledged. >>>>>> Given a value of N, a hypothetical TCP connection following >>>>>> exponential backoff with an initial RTO of TCP_RTO_MIN would >>>>>> retransmit N times before killing the connection at the (N+1)th RTO. >>>>>> >>>>>> The default value of 15 yields a hypothetical timeout of 924.6 >>>>>> seconds and is a lower bound for the effective timeout. >>>>>> TCP will effectively time out at the first RTO which exceeds the >>>>>> hypothetical timeout. >>>>>> >>>>>> RFC 1122 recommends at least 100 seconds for the timeout, >>>>>> which corresponds to a value of at least 8. >>>>>> >>>>>> Isn't it possible that the connection suddenly goes down in between a >>>>>> transaction request and its reply but with all TCP segments being >>>>>> ACKed? >>>>> >>>>> Right. If the client already sent the request and only waits for a >>>>> reply, >>>>> the retransmission timeout will not have any effect. An idle TCP session >>>>> may stay open practically forever, because it is designed to survive >>>>> network >>>>> disruptions. There is no such thing as a TCP timeout in a general case. >>>>> >>>> >>>> I was wondering if you have more thoughts on this? Shoul
[ovs-dev] [PATCH ovn v2] utilities: increase OVSDB inactivity probe interval for ovn-*ctl
For large OVN_Southbound (or other) databases the default interval of 5000 ms
could be not sufficient to run. This patch adds configuration of OVSDB
inactivity probes for ovn-*ctl utilities.
Initially, on the utility start the hardcoded value of 12 ms is set.
For daemon-mode it is possible to configure intervals in OVN Northbound
database:
OVN_Northbound.NB_Global.options.dbctl_inactivity_probe for ovn-nbctl and
ovn-sbctl utilities.
If no DB configuration option was provided, the initial (12 ms) interval
is left.
Signed-off-by: Vladislav Odintsov
---
lib/ovn-util.h | 2 ++
ovn-nb.xml | 20
utilities/ovn-dbctl.c| 18 ++
utilities/ovn-dbctl.h| 1 +
utilities/ovn-ic-nbctl.c | 4
utilities/ovn-ic-sbctl.c | 4
utilities/ovn-nbctl.c| 15 +++
utilities/ovn-sbctl.c| 15 +++
8 files changed, 79 insertions(+)
diff --git a/lib/ovn-util.h b/lib/ovn-util.h
index 7cf861dbc..47e53ca74 100644
--- a/lib/ovn-util.h
+++ b/lib/ovn-util.h
@@ -154,6 +154,8 @@ void set_idl_probe_interval(struct ovsdb_idl *idl, const
char *remote,
#define OVN_MAX_DP_VXLAN_KEY ((1u << 12) - 1)
#define OVN_MAX_DP_VXLAN_KEY_LOCAL (OVN_MAX_DP_KEY - OVN_MAX_DP_GLOBAL_NUM)
+#define DEFAULT_UTILS_PROBE_INTERVAL_MSEC 12
+
struct hmap;
void ovn_destroy_tnlids(struct hmap *tnlids);
bool ovn_add_tnlid(struct hmap *set, uint32_t tnlid);
diff --git a/ovn-nb.xml b/ovn-nb.xml
index fd32070f2..a82f31a92 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -215,6 +215,26 @@
+
+
+ The inactivity probe interval of the connection to the OVN Northbound
+ and Southbound databases from ovn-nbctl and
+ ovn-sbctl utilities respectively, in milliseconds.
+ If the value is zero, it disables the connection keepalive feature.
+
+
+
+ If the value is nonzero, then it will be forced to a value of
+ at least 1000 ms.
+
+
+
+ If the value less then zero, then the default inactivity probe
+ interval for ovn-nbctl and ovn-sbctl would
+ be left intact (12 ms).
+
+
+
When used, this configuration value specifies the time, in
diff --git a/utilities/ovn-dbctl.c b/utilities/ovn-dbctl.c
index 369a6a663..c6aebcbbb 100644
--- a/utilities/ovn-dbctl.c
+++ b/utilities/ovn-dbctl.c
@@ -205,6 +205,9 @@ ovn_dbctl_main(int argc, char *argv[],
ovsdb_idl_set_remote(idl, db, daemon_mode);
ovsdb_idl_set_leader_only(idl, leader_only);
+/* Set reasonable high probe interval. */
+set_idl_probe_interval(idl, db, DEFAULT_UTILS_PROBE_INTERVAL_MSEC);
+
if (daemon_mode) {
server_loop(dbctl_options, idl, argc, argv_);
} else {
@@ -1094,6 +1097,17 @@ out:
free(argv);
}
+static void
+update_inactivity_probe(struct server_cmd_run_ctx *ctx)
+{
+int inactivity_probe = ctx->dbctl_options->get_inactivity_probe(ctx->idl);
+if (inactivity_probe < 0) {
+inactivity_probe = DEFAULT_UTILS_PROBE_INTERVAL_MSEC;
+}
+
+set_idl_probe_interval(ctx->idl, db, inactivity_probe);
+}
+
static void
server_loop(const struct ovn_dbctl_options *dbctl_options,
struct ovsdb_idl *idl, int argc, char *argv[])
@@ -1125,6 +1139,10 @@ server_loop(const struct ovn_dbctl_options
*dbctl_options,
for (;;) {
update_ssl_config();
+
+/* Configure inactivity probe from connected DB. */
+update_inactivity_probe(&server_cmd_run_ctx);
+
memory_run();
if (memory_should_report()) {
struct simap usage = SIMAP_INITIALIZER(&usage);
diff --git a/utilities/ovn-dbctl.h b/utilities/ovn-dbctl.h
index a1fbede6b..54c232dd6 100644
--- a/utilities/ovn-dbctl.h
+++ b/utilities/ovn-dbctl.h
@@ -52,6 +52,7 @@ struct ovn_dbctl_options {
const struct timer *wait_timeout,
long long int start_time, bool print_wait_time);
+int (*get_inactivity_probe)(struct ovsdb_idl *);
struct ctl_context *(*ctx_create)(void);
void (*ctx_destroy)(struct ctl_context *);
};
diff --git a/utilities/ovn-ic-nbctl.c b/utilities/ovn-ic-nbctl.c
index f3d8039a8..19d8b054f 100644
--- a/utilities/ovn-ic-nbctl.c
+++ b/utilities/ovn-ic-nbctl.c
@@ -116,6 +116,10 @@ main(int argc, char *argv[])
ovsdb_idl_set_remote(idl, db, false);
ovsdb_idl_set_db_change_aware(idl, false);
ovsdb_idl_set_leader_only(idl, leader_only);
+
+/* Set reasonable high probe interval. */
+set_idl_probe_interval(idl, db, DEFAULT_UTILS_PROBE_INTERVAL_MSEC);
+
run_prerequisites(commands, n_commands, idl);
/* Execute the commands.
diff --git a/utilities/ovn-ic-sbctl.c b/utilities/ovn-ic-sbctl.c
index 3060b48b9..215d09d30 100644
--- a/utilities/ovn-ic-sbctl.c
+++ b/utilities/ovn-ic-sbctl.c
@@ -115,6 +115,10 @@ main(int argc, char *argv
Re: [ovs-dev] [PATCH ovn] utilities: disable OVSDB inactivity probes for non-daemon ovn-nbctl
> On 18 Apr 2023, at 16:59, Dumitru Ceara wrote: > > On 4/14/23 15:37, Vladislav Odintsov wrote: >> Hi Dumitru, >> >>> On 13 Apr 2023, at 11:55, Dumitru Ceara wrote: >>> >>> Hi Vladislav, >>> >>> On 4/3/23 12:08, Ilya Maximets wrote: >>>> On 3/31/23 17:17, Dumitru Ceara wrote: >>>>> On 3/31/23 16:51, Vladislav Odintsov wrote: >>>>>> As I understood from Ilya, in case of one-command run of ovn-sbctl >>>>>> (non-daemon mode), it doesn’t make sense to have client -> server >>>>>> inactivity probes. If cable is unplugged, will just hit tcp session >>>>>> timeout, IIUC. >>>>>> Please correct me if I’m wrong. >>>>>> >>>>> >>>>> You're right but the default timeouts are quite large for TCP sessions: >>>>> >>>>> With keepalives default: >>>>> tcp_keepalive_time - INTEGER >>>>> How often TCP sends out keepalive messages when keepalive is enabled. >>>>> Default: 2hours. >>>>> >>>>> tcp_keepalive_probes - INTEGER >>>>> How many keepalive probes TCP sends out, until it decides that the >>>>> connection is broken. Default value: 9. >>>>> >>>>> tcp_keepalive_intvl - INTEGER >>>>> How frequently the probes are send out. Multiplied by >>>>> tcp_keepalive_probes it is time to kill not responding connection, >>>>> after probes started. Default value: 75sec i.e. connection >>>>> will be aborted after ~11 minutes of retries. >>>>> >>>>> DB clients don't even enable tcp keepalives IIRC. >>>>> >>>>> So then we depend retransmits timing out: >>>>> tcp_retries2 - INTEGER >>>>> This value influences the timeout of an alive TCP connection, >>>>> when RTO retransmissions remain unacknowledged. >>>>> Given a value of N, a hypothetical TCP connection following >>>>> exponential backoff with an initial RTO of TCP_RTO_MIN would >>>>> retransmit N times before killing the connection at the (N+1)th RTO. >>>>> >>>>> The default value of 15 yields a hypothetical timeout of 924.6 >>>>> seconds and is a lower bound for the effective timeout. >>>>> TCP will effectively time out at the first RTO which exceeds the >>>>> hypothetical timeout. >>>>> >>>>> RFC 1122 recommends at least 100 seconds for the timeout, >>>>> which corresponds to a value of at least 8. >>>>> >>>>> Isn't it possible that the connection suddenly goes down in between a >>>>> transaction request and its reply but with all TCP segments being >>>>> ACKed? >>>> >>>> Right. If the client already sent the request and only waits for a >>>> reply, >>>> the retransmission timeout will not have any effect. An idle TCP session >>>> may stay open practically forever, because it is designed to survive >>>> network >>>> disruptions. There is no such thing as a TCP timeout in a general case. >>>> >>> >>> I was wondering if you have more thoughts on this? Should we go for the >>> approach where OVN sets the probe interval to a "reasonably large" >>> value by default? For example, using 30s would mean failure after ~60 >>> seconds of inactivity. >> >> Actually I’m okay with your proposal to set a reasonable high inactivity >> probe (120/180 seconds?). >> Maybe it should be not only for non-daemon operation of dbctl but also >> for all modes? >> > > It's probably a good idea, yes. > >> Alternatively, I thought it could be useful to add a new command line >> option like --inactivity-probe=N for the utilities to allow the user to >> choose and set interval which is needed in each case. >> >> What do you think about it? >> > > Northd uses NB_Global.options:northd_probe_interval as inactivity > interval. Can we do the same thing and use as default the high value > until the first successful connection to the NB? Good idea, I’ll dig into this next week, thanks. > >>> >>> Thanks, >>> Dumitru >>> >>>>> >>>>>>> On 31 Mar 2023, at 15:55, Dumitru Ceara wrote: >>>>>>> >>>>>>>
Re: [ovs-dev] [PATCH ovn] utilities: disable OVSDB inactivity probes for non-daemon ovn-nbctl
Hi Dumitru, > On 13 Apr 2023, at 11:55, Dumitru Ceara wrote: > > Hi Vladislav, > > On 4/3/23 12:08, Ilya Maximets wrote: >> On 3/31/23 17:17, Dumitru Ceara wrote: >>> On 3/31/23 16:51, Vladislav Odintsov wrote: >>>> As I understood from Ilya, in case of one-command run of ovn-sbctl >>>> (non-daemon mode), it doesn’t make sense to have client -> server >>>> inactivity probes. If cable is unplugged, will just hit tcp session >>>> timeout, IIUC. >>>> Please correct me if I’m wrong. >>>> >>> >>> You're right but the default timeouts are quite large for TCP sessions: >>> >>> With keepalives default: >>> tcp_keepalive_time - INTEGER >>> How often TCP sends out keepalive messages when keepalive is enabled. >>> Default: 2hours. >>> >>> tcp_keepalive_probes - INTEGER >>> How many keepalive probes TCP sends out, until it decides that the >>> connection is broken. Default value: 9. >>> >>> tcp_keepalive_intvl - INTEGER >>> How frequently the probes are send out. Multiplied by >>> tcp_keepalive_probes it is time to kill not responding connection, >>> after probes started. Default value: 75sec i.e. connection >>> will be aborted after ~11 minutes of retries. >>> >>> DB clients don't even enable tcp keepalives IIRC. >>> >>> So then we depend retransmits timing out: >>> tcp_retries2 - INTEGER >>> This value influences the timeout of an alive TCP connection, >>> when RTO retransmissions remain unacknowledged. >>> Given a value of N, a hypothetical TCP connection following >>> exponential backoff with an initial RTO of TCP_RTO_MIN would >>> retransmit N times before killing the connection at the (N+1)th RTO. >>> >>> The default value of 15 yields a hypothetical timeout of 924.6 >>> seconds and is a lower bound for the effective timeout. >>> TCP will effectively time out at the first RTO which exceeds the >>> hypothetical timeout. >>> >>> RFC 1122 recommends at least 100 seconds for the timeout, >>> which corresponds to a value of at least 8. >>> >>> Isn't it possible that the connection suddenly goes down in between a >>> transaction request and its reply but with all TCP segments being >>> ACKed? >> >> Right. If the client already sent the request and only waits for a reply, >> the retransmission timeout will not have any effect. An idle TCP session >> may stay open practically forever, because it is designed to survive network >> disruptions. There is no such thing as a TCP timeout in a general case. >> > > I was wondering if you have more thoughts on this? Should we go for the > approach where OVN sets the probe interval to a "reasonably large" > value by default? For example, using 30s would mean failure after ~60 > seconds of inactivity. Actually I’m okay with your proposal to set a reasonable high inactivity probe (120/180 seconds?). Maybe it should be not only for non-daemon operation of dbctl but also for all modes? Alternatively, I thought it could be useful to add a new command line option like --inactivity-probe=N for the utilities to allow the user to choose and set interval which is needed in each case. What do you think about it? > > Thanks, > Dumitru > >>> >>>>> On 31 Mar 2023, at 15:55, Dumitru Ceara wrote: >>>>> >>>>> On 3/31/23 14:46, Vladislav Odintsov wrote: >>>>>> Hi Dumitru, >>>>>> >>>>>>> On 31 Mar 2023, at 15:01, Dumitru Ceara wrote: >>>>>>> >>>>>>> On 3/31/23 11:43, Ales Musil wrote: >>>>>>>> On Thu, Mar 23, 2023 at 8:25 PM Vladislav Odintsov >>>>>>>> wrote: >>>>>>>> >>>>>>>>> For large OVN_Southbound DBs defatult interval of 5000 ms could be not >>>>>>>>> sufficient. This patch disables OVSDB inactivity probes for ovn-*ctl >>>>>>>>> running >>>>>>>>> in non-daemon mode. >>>>>>>>> >>>>>>>>> Signed-off-by: Vladislav Odintsov >>>>>>>>> --- >>>>>>>>> utilities/ovn-dbctl.c | 3 +++ >>>>>>>>> 1 file changed, 3 insertions(+) >>>>>>>>> >>>>>>>&
Re: [ovs-dev] [ovn] ha-chassis-group false positive failover
And as a follow-up, I see sometimes next error message in ovn-controller log, though there is a configured much higher limit in seconds for inactivity probe value for the chassis: ovs|04426|rconn|ERR|unix:/run/openvswitch/br-int.mgmt: no response to inactivity probe after 8 seconds, disconnecting ovs|26560|rconn|ERR|unix:/run/openvswitch/br-int.mgmt: no response to inactivity probe after 10 seconds, disconnecting server with first log message: # ovs-vsctl get open . external_ids:ovn-openflow-probe-interval "30" server with second log message: # ovs-vsctl get open . external_ids:ovn-openflow-probe-interval "60" > On 30 Mar 2023, at 23:19, Vladislav Odintsov wrote: > > Hi all, > > I’m facing a false positive failover in the event of openflow connection got > dropped after inactivity probe timeout due to high load of ovn-controller > handling huge amount of ovsdb updates. > I wonder wether its a bug or I have to tune any specifics. See ovn-controller > logs: > > 2023-03-30T07:57:24.469Z|58440|inc_proc_eng|INFO|node: logical_flow_output, > recompute (failed handler for input port_groups) took 35774ms > 2023-03-30T07:57:28.521Z|58441|lflow_cache|INFO|Detected cache inactivity > (last active 40006 ms ago): trimming cache > 2023-03-30T07:57:28.528Z|58442|timeval|WARN|Unreasonably long 40084ms poll > interval (32947ms user, 6968ms system) > 2023-03-30T07:57:28.528Z|58443|timeval|WARN|faults: 43468 minor, 0 major > ….. > 2023-03-30T07:57:48.784Z|58496|reconnect|ERR|ssl::6642: no response to > inactivity probe after 60.2 seconds, disconnecting > 2023-03-30T07:57:48.784Z|58497|reconnect|INFO|ssl::6642: connection > dropped > 2023-03-30T07:57:48.905Z|58498|main|INFO|OVNSB commit failed, force recompute > next time. > 2023-03-30T07:57:49.786Z|58499|reconnect|INFO|ssl::6642: connecting... > 2023-03-30T07:57:49.924Z|58500|reconnect|INFO|ssl::6642: connected > 2023-03-30T07:57:29.781Z|58501|poll_loop|INFO|wakeup due to 0-ms timeout at > lib/stream-ssl.c:838 (74% CPU usage) > 2023-03-30T07:57:29.836Z|58502|poll_loop|INFO|wakeup due to 0-ms timeout at > lib/stream-ssl.c:838 (74% CPU usage) > …. > 2023-03-30T07:57:05.976Z|58545|poll_loop|INFO|wakeup due to 0-ms timeout at > lib/stream-ssl.c:838 (101% CPU usage) > 2023-03-30T07:57:07.002Z|58546|memory|INFO|peak resident set size grew 54% in > last 682257.2 seconds, from 4435696 kB to 6824820 kB > 2023-03-30T07:57:07.002Z|58547|memory|INFO|idl-cells-OVN_Southbound:11491359 > idl-cells-Open_vSwitch:14416 lflow-cache-entries-cache-expr:530298 > lflow-cache-entries-cache-matches:31770 lflow-cache-size-KB:769553 > local_datapath_usage-KB:630 > ofctrl_desired_flow_usage-KB:577052 ofctrl_installed_flow_usage-KB:409538 > ofctrl_sb_flow_ref_usage-KB:273707 > … > 2023-03-30T07:57:31.667Z|58552|rconn|WARN|unix:/run/openvswitch/br-int.mgmt: > connection dropped (Broken pipe) > 2023-03-30T07:57:31.739Z|58553|binding|INFO|Releasing lport cr-xxx from this > chassis (sb_readonly=0) > 2023-03-30T07:57:31.739Z|58554|if_status|WARN|Dropped 1 log messages in last > 1254725 seconds (most recently, 1254725 seconds ago) due to excessive rate > 2023-03-30T07:57:31.739Z|58555|if_status|WARN|Trying to release unknown > interface cr-xxx > 2023-03-30T07:57:31.743Z|58556|binding|INFO|Releasing lport cr-yyy from this > chassis (sb_readonly=0) > 2023-03-30T07:57:31.743Z|58557|binding|INFO|Releasing lport cr-zzz from this > chassis (sb_readonly=0) > … > > After some time these ports are claimed back: > > 2023-03-30T07:57:49.320Z|59137|rconn|INFO|unix:/run/openvswitch/br-int.mgmt: > connecting... > 2023-03-30T07:57:49.320Z|59138|rconn|INFO|unix:/run/openvswitch/br-int.mgmt: > connected > 2023-03-30T07:57:49.523Z|59139|poll_loop|INFO|wakeup due to 0-ms timeout at > controller/ovn-controller.c:4296 (99% CPU usage) > 2023-03-30T07:57:49.574Z|59140|poll_loop|INFO|wakeup due to 0-ms timeout at > controller/ovn-controller.c:4286 (99% CPU usage) > 2023-03-30T07:58:01.451Z|59141|poll_loop|INFO|wakeup due to [POLLIN] on fd 22 > (:34736<->:6642) at lib/stream-ssl.c:836 (99% CPU usage) > 2023-03-30T07:58:02.449Z|59142|binding|INFO|Claiming lport cr-xxx for this > chassis. > 2023-03-30T07:58:02.449Z|59143|binding|INFO|cr-xxx: Claiming xx:xx:xx:xx:xx > x.x.x.x/xx > 2023-03-30T07:58:02.453Z|59144|binding|INFO|Claiming lport cr-yyy for this > chassis. > 2023-03-30T07:58:02.453Z|59145|binding|INFO|cr-yyy: Claiming > yy:yy:yy:yy:yy:yy y.y.y.y/yy > … > > Previously I’ve met with similar problem but the openflow probe interval was > 30 seconds and I set it to 60 and then to 120 seconds. > But it seems that OVS was configured on default inactivity probe timeout for > openflow - 6
Re: [ovs-dev] [PATCH ovn] utilities: disable OVSDB inactivity probes for non-daemon ovn-nbctl
As I understood from Ilya, in case of one-command run of ovn-sbctl (non-daemon
mode), it doesn’t make sense to have client -> server inactivity probes. If
cable is unplugged, will just hit tcp session timeout, IIUC.
Please correct me if I’m wrong.
> On 31 Mar 2023, at 15:55, Dumitru Ceara wrote:
>
> On 3/31/23 14:46, Vladislav Odintsov wrote:
>> Hi Dumitru,
>>
>>> On 31 Mar 2023, at 15:01, Dumitru Ceara wrote:
>>>
>>> On 3/31/23 11:43, Ales Musil wrote:
>>>> On Thu, Mar 23, 2023 at 8:25 PM Vladislav Odintsov
>>>> wrote:
>>>>
>>>>> For large OVN_Southbound DBs defatult interval of 5000 ms could be not
>>>>> sufficient. This patch disables OVSDB inactivity probes for ovn-*ctl
>>>>> running
>>>>> in non-daemon mode.
>>>>>
>>>>> Signed-off-by: Vladislav Odintsov
>>>>> ---
>>>>> utilities/ovn-dbctl.c | 3 +++
>>>>> 1 file changed, 3 insertions(+)
>>>>>
>>>>> diff --git a/utilities/ovn-dbctl.c b/utilities/ovn-dbctl.c
>>>>> index 369a6a663..4307a5cae 100644
>>>>> --- a/utilities/ovn-dbctl.c
>>>>> +++ b/utilities/ovn-dbctl.c
>>>>> @@ -208,6 +208,9 @@ ovn_dbctl_main(int argc, char *argv[],
>>>>>if (daemon_mode) {
>>>>>server_loop(dbctl_options, idl, argc, argv_);
>>>>>} else {
>>>>> +/* Disable OVSDB probe interval for non-daemon mode. */
>>>>> +ovsdb_idl_set_probe_interval(idl, 0);
>>>
>>> I think I'd avoid using the idl function directly and call instead:
>>>
>>> set_idl_probe_interval(idl, 0);
>>>
>>> Just to keep it aligned with all other uses in OVN. I can patch that at
>>> apply time if it looks OK to you.
>>
>> I’ve got no objections here.
>> Small nit: set_idl_probe_interval function needs also a remote. Like this:
>>
>> set_idl_probe_interval(idl, db, 0);
>>
>> Also, please correct typo in commit message: defatult -> default.
>>
>
> In light of the ovs-discuss thread [0] is it maybe better to just set
> this probe interval to a very high value instead? That's for the case
> when ovn-nbctl/sbctl daemon <-> ovsdb-server connection dies because of
> for example cable being unplugged somewhere on the way between the two.
>
> [0]
> https://mail.openvswitch.org/pipermail/ovs-discuss/2023-March/052324.html
>
>>>
>>>>> +
>>>>>struct ctl_command *commands;
>>>>>size_t n_commands;
>>>>>char *error;
>>>>> --
>>>>> 2.36.1
>>>>>
>>>>> ___
>>>>> dev mailing list
>>>>> d...@openvswitch.org
>>>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>>>
>>>>>
>>>> Looks good to me, thanks.
>>>>
>>>> Reviewed-by: Ales Musil
>>>>
>>>
>>> Vladislav, Ales, I was thinking of backporting this to stable branches
>>> too, what do you think?
>>>
>>> Thanks,
>>> Dumitru
>>
>>
>> Regards,
>> Vladislav Odintsov
>>
>>
>
> ___
> dev mailing list
> d...@openvswitch.org <mailto:d...@openvswitch.org>
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Regards,
Vladislav Odintsov
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn] utilities: disable OVSDB inactivity probes for non-daemon ovn-nbctl
Hi Dumitru,
> On 31 Mar 2023, at 15:01, Dumitru Ceara wrote:
>
> On 3/31/23 11:43, Ales Musil wrote:
>> On Thu, Mar 23, 2023 at 8:25 PM Vladislav Odintsov
>> wrote:
>>
>>> For large OVN_Southbound DBs defatult interval of 5000 ms could be not
>>> sufficient. This patch disables OVSDB inactivity probes for ovn-*ctl
>>> running
>>> in non-daemon mode.
>>>
>>> Signed-off-by: Vladislav Odintsov
>>> ---
>>> utilities/ovn-dbctl.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/utilities/ovn-dbctl.c b/utilities/ovn-dbctl.c
>>> index 369a6a663..4307a5cae 100644
>>> --- a/utilities/ovn-dbctl.c
>>> +++ b/utilities/ovn-dbctl.c
>>> @@ -208,6 +208,9 @@ ovn_dbctl_main(int argc, char *argv[],
>>> if (daemon_mode) {
>>> server_loop(dbctl_options, idl, argc, argv_);
>>> } else {
>>> +/* Disable OVSDB probe interval for non-daemon mode. */
>>> +ovsdb_idl_set_probe_interval(idl, 0);
>
> I think I'd avoid using the idl function directly and call instead:
>
> set_idl_probe_interval(idl, 0);
>
> Just to keep it aligned with all other uses in OVN. I can patch that at
> apply time if it looks OK to you.
I’ve got no objections here.
Small nit: set_idl_probe_interval function needs also a remote. Like this:
set_idl_probe_interval(idl, db, 0);
Also, please correct typo in commit message: defatult -> default.
>
>>> +
>>> struct ctl_command *commands;
>>> size_t n_commands;
>>> char *error;
>>> --
>>> 2.36.1
>>>
>>> ___
>>> dev mailing list
>>> d...@openvswitch.org
>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>>>
>>>
>> Looks good to me, thanks.
>>
>> Reviewed-by: Ales Musil
>>
>
> Vladislav, Ales, I was thinking of backporting this to stable branches
> too, what do you think?
>
> Thanks,
> Dumitru
Regards,
Vladislav Odintsov
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovsdb: add unixctl cmd to show memory-trim-on-compaction setting
> On 21 Mar 2023, at 17:01, Ilya Maximets wrote: > > On 3/20/23 13:51, Vladislav Odintsov wrote: >> No, my usecase with 2.17 is that I just want to check agains a running >> process wether memory compaction is enabled or not without searching >> specific line in logs, which in addition can be rotated. > > OK, but can you just set it without checking? I mean, it will be the > same number of interactions, or less if the status needs changing. I just wanted to have a way to get this value automatically. Actually, I did this for my local build and afther I’ve just upgraded to 3.1. If you mean community doesn’t need this - I’m okay with that ;) > >> >>> On 20 Mar 2023, at 15:27, Ilya Maximets wrote: >>> >>> On 3/20/23 13:20, Vladislav Odintsov wrote: >>>> Hi Ilya, >>>> >>>> Ah, I didn’t see that its default was changed in newer versions... >>>> We run 2.17 where it’s off by default and I decided to submit a patch >>>> which is useful for that version. >>>> Anyway my opinion is if user has an ability to change the setting, it >>>> should be possible to get its actual value. At least in versions were it’s >>>> off by default. >>> >>> We also have this: >>> https://patchwork.ozlabs.org/project/openvswitch/patch/397efb8df22b13c19c326a3eecb48ada93c83420.ca...@redhat.com/ >>> >>> This one we can actually treat as a bug fix and backport down to 2.17. >>> In case the logging is what is bothering you. I know that ovn-k8s, >>> for example, is calling this appctl frequently littering the log. >>> The change can fix at least that. >>> >>> Best regards, Ilya Maximets. >>> >>>> >>>>> On 20 Mar 2023, at 15:07, Ilya Maximets wrote: >>>>> >>>>> On 3/20/23 10:24, Vladislav Odintsov wrote: >>>>>> In commit [1] there was added support to enable memory trimming on OVSDB >>>>>> tlog >>>>>> compation. However there was no option to get current setting value >>>>>> except >>>>>> log parsing. This patch adds new unixctl command >>>>>> 'ovsdb-server/show-memory-trim-on-compaction' to print current setting >>>>>> value. >>>>>> >>>>>> 1: >>>>>> https://github.com/openvswitch/ovs/commit/f38f98a2c0dd7fcaf20fbe11d1e67a9b2afc0b2a >>>>>> >>>>>> Signed-off-by: Vladislav Odintsov >>>>>> --- >>>>>> NEWS | 4 >>>>>> ovsdb/ovsdb-server.c | 28 >>>>>> 2 files changed, 32 insertions(+) >>>>>> >>>>>> diff --git a/NEWS b/NEWS >>>>>> index 72b9024e6..8515f4aaa 100644 >>>>>> --- a/NEWS >>>>>> +++ b/NEWS >>>>>> @@ -17,6 +17,10 @@ Post-v3.1.0 >>>>>>in order to create OVSDB sockets with access mode of 0770. >>>>>>- QoS: >>>>>> * Added new configuration option 'jitter' for a linux-netem QoS >>>>>> type. >>>>>> + - OVSDB: >>>>>> + * New unixctl command >>>>>> 'ovsdb-server/show-memory-trim-on-compaction'. >>>>>> + This command shows current value for memory trimming setting for >>>>>> + OVSDB server. >>>>> >>>>> Hi, Vladislav. The memory trimming is enabled by default since 3.0. >>>>> And I'm not aware of any cases where it is beneficial to disable it. >>>>> The current appctl call was mostly kept for backward compatibility >>>>> and should be deprecated and removed in one of the future releases. >>>>> So, I'm not sure if we actually need to add a new knob for status >>>>> checking, unless you actually want to disable the trimming. >>>>> >>>>> What do you think? >>>>> >>>>> Best regards, Ilya Maximets. >>>> >>>> >>>> Regards, >>>> Vladislav Odintsov >>>> >>> >> >> >> Regards, >> Vladislav Odintsov >> > > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [ovn] ha-chassis-group false positive failover
inactivity probe, is it possible and should I configure from ovs-vswitchd side? 4. There is a warning on try to release unknown interface, which was relased right before. Is it normal situation or also should be investigated? Thanks. Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn 0/6] Inactivity probe configuration for ic, controller-vtep
Hi Numan, thanks for the review and patches applying. I’ve re-submitted the last patch here: https://patchwork.ozlabs.org/project/ovn/patch/20230323192520.3903330-1-odiv...@gmail.com/ > On 23 Mar 2023, at 22:15, Numan Siddique wrote: > > On Sat, Mar 18, 2023 at 7:50 PM Vladislav Odintsov <mailto:odiv...@gmail.com>> wrote: >> >> This patch series adds support to configure inactivity probe for ovn-ic >> and ovn-controller-vtep. >> In first commit is just a preparation for adding support: the duplicated >> logic from ovn-controller and ovn-northd is moved to lib/ovn-util. >> >> Additionally methods to monitor OVSDB connection status were added to >> ovn-ic and ovn-controller-vtep. >> >> Vladislav Odintsov (6): >> controller,northd: move inactivity probe configuration to lib/ >> ic: add support to configure ovsdb inactivity probe >> controller-vtep: add support to configure inactivity probe interval >> controller-vtep: add unixctl commands to show DB connection status >> ovn-ic: add unixctl commands to report db connection status >> NEWS: add info about ic/controller-vtep inactivity probe support > > Thanks for adding this feature. > > I applied the series to the main branch. Note that I've not reviewed > this patch - > http://patchwork.ozlabs.org/project/ovn/patch/20230319005427.3796325-1-odiv...@gmail.com/ > > Can you please submit separately. CI has not run for this patch maybe > due to the patch number 7/6. > > Numan > >> >> NEWS | 2 ++ >> controller-vtep/ovn-controller-vtep.8.xml | 14 + >> controller-vtep/ovn-controller-vtep.c | 22 ++ >> controller/ovn-controller.c | 8 ++--- >> ic/ovn-ic.c | 37 +++ >> lib/ovn-util.c| 22 ++ >> lib/ovn-util.h| 4 +++ >> northd/ovn-northd.c | 30 +++--- >> ovn-ic-nb.xml | 14 + >> ovn-nb.xml| 13 >> 10 files changed, 135 insertions(+), 31 deletions(-) >> >> -- >> 2.36.1 >> >> ___ >> dev mailing list >> d...@openvswitch.org <mailto:d...@openvswitch.org> >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> > ___ > dev mailing list > d...@openvswitch.org <mailto:d...@openvswitch.org> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn] utilities: disable OVSDB inactivity probes for non-daemon ovn-nbctl
For large OVN_Southbound DBs defatult interval of 5000 ms could be not
sufficient. This patch disables OVSDB inactivity probes for ovn-*ctl running
in non-daemon mode.
Signed-off-by: Vladislav Odintsov
---
utilities/ovn-dbctl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/utilities/ovn-dbctl.c b/utilities/ovn-dbctl.c
index 369a6a663..4307a5cae 100644
--- a/utilities/ovn-dbctl.c
+++ b/utilities/ovn-dbctl.c
@@ -208,6 +208,9 @@ ovn_dbctl_main(int argc, char *argv[],
if (daemon_mode) {
server_loop(dbctl_options, idl, argc, argv_);
} else {
+/* Disable OVSDB probe interval for non-daemon mode. */
+ovsdb_idl_set_probe_interval(idl, 0);
+
struct ctl_command *commands;
size_t n_commands;
char *error;
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovsdb: add unixctl cmd to show memory-trim-on-compaction setting
No, my usecase with 2.17 is that I just want to check agains a running process wether memory compaction is enabled or not without searching specific line in logs, which in addition can be rotated. > On 20 Mar 2023, at 15:27, Ilya Maximets wrote: > > On 3/20/23 13:20, Vladislav Odintsov wrote: >> Hi Ilya, >> >> Ah, I didn’t see that its default was changed in newer versions... >> We run 2.17 where it’s off by default and I decided to submit a patch which >> is useful for that version. >> Anyway my opinion is if user has an ability to change the setting, it should >> be possible to get its actual value. At least in versions were it’s off by >> default. > > We also have this: > https://patchwork.ozlabs.org/project/openvswitch/patch/397efb8df22b13c19c326a3eecb48ada93c83420.ca...@redhat.com/ > > This one we can actually treat as a bug fix and backport down to 2.17. > In case the logging is what is bothering you. I know that ovn-k8s, > for example, is calling this appctl frequently littering the log. > The change can fix at least that. > > Best regards, Ilya Maximets. > >> >>> On 20 Mar 2023, at 15:07, Ilya Maximets wrote: >>> >>> On 3/20/23 10:24, Vladislav Odintsov wrote: >>>> In commit [1] there was added support to enable memory trimming on OVSDB >>>> tlog >>>> compation. However there was no option to get current setting value except >>>> log parsing. This patch adds new unixctl command >>>> 'ovsdb-server/show-memory-trim-on-compaction' to print current setting >>>> value. >>>> >>>> 1: >>>> https://github.com/openvswitch/ovs/commit/f38f98a2c0dd7fcaf20fbe11d1e67a9b2afc0b2a >>>> >>>> Signed-off-by: Vladislav Odintsov >>>> --- >>>> NEWS | 4 >>>> ovsdb/ovsdb-server.c | 28 >>>> 2 files changed, 32 insertions(+) >>>> >>>> diff --git a/NEWS b/NEWS >>>> index 72b9024e6..8515f4aaa 100644 >>>> --- a/NEWS >>>> +++ b/NEWS >>>> @@ -17,6 +17,10 @@ Post-v3.1.0 >>>>in order to create OVSDB sockets with access mode of 0770. >>>>- QoS: >>>> * Added new configuration option 'jitter' for a linux-netem QoS type. >>>> + - OVSDB: >>>> + * New unixctl command 'ovsdb-server/show-memory-trim-on-compaction'. >>>> + This command shows current value for memory trimming setting for >>>> + OVSDB server. >>> >>> Hi, Vladislav. The memory trimming is enabled by default since 3.0. >>> And I'm not aware of any cases where it is beneficial to disable it. >>> The current appctl call was mostly kept for backward compatibility >>> and should be deprecated and removed in one of the future releases. >>> So, I'm not sure if we actually need to add a new knob for status >>> checking, unless you actually want to disable the trimming. >>> >>> What do you think? >>> >>> Best regards, Ilya Maximets. >> >> >> Regards, >> Vladislav Odintsov >> > Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] ovsdb: add unixctl cmd to show memory-trim-on-compaction setting
Hi Ilya, Ah, I didn’t see that its default was changed in newer versions... We run 2.17 where it’s off by default and I decided to submit a patch which is useful for that version. Anyway my opinion is if user has an ability to change the setting, it should be possible to get its actual value. At least in versions were it’s off by default. > On 20 Mar 2023, at 15:07, Ilya Maximets wrote: > > On 3/20/23 10:24, Vladislav Odintsov wrote: >> In commit [1] there was added support to enable memory trimming on OVSDB tlog >> compation. However there was no option to get current setting value except >> log parsing. This patch adds new unixctl command >> 'ovsdb-server/show-memory-trim-on-compaction' to print current setting value. >> >> 1: >> https://github.com/openvswitch/ovs/commit/f38f98a2c0dd7fcaf20fbe11d1e67a9b2afc0b2a >> >> Signed-off-by: Vladislav Odintsov >> --- >> NEWS | 4 >> ovsdb/ovsdb-server.c | 28 >> 2 files changed, 32 insertions(+) >> >> diff --git a/NEWS b/NEWS >> index 72b9024e6..8515f4aaa 100644 >> --- a/NEWS >> +++ b/NEWS >> @@ -17,6 +17,10 @@ Post-v3.1.0 >>in order to create OVSDB sockets with access mode of 0770. >>- QoS: >> * Added new configuration option 'jitter' for a linux-netem QoS type. >> + - OVSDB: >> + * New unixctl command 'ovsdb-server/show-memory-trim-on-compaction'. >> + This command shows current value for memory trimming setting for >> + OVSDB server. > > Hi, Vladislav. The memory trimming is enabled by default since 3.0. > And I'm not aware of any cases where it is beneficial to disable it. > The current appctl call was mostly kept for backward compatibility > and should be deprecated and removed in one of the future releases. > So, I'm not sure if we actually need to add a new knob for status > checking, unless you actually want to disable the trimming. > > What do you think? > > Best regards, Ilya Maximets. Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ovsdb: add unixctl cmd to show memory-trim-on-compaction setting
In commit [1] there was added support to enable memory trimming on OVSDB tlog
compation. However there was no option to get current setting value except
log parsing. This patch adds new unixctl command
'ovsdb-server/show-memory-trim-on-compaction' to print current setting value.
1:
https://github.com/openvswitch/ovs/commit/f38f98a2c0dd7fcaf20fbe11d1e67a9b2afc0b2a
Signed-off-by: Vladislav Odintsov
---
NEWS | 4
ovsdb/ovsdb-server.c | 28
2 files changed, 32 insertions(+)
diff --git a/NEWS b/NEWS
index 72b9024e6..8515f4aaa 100644
--- a/NEWS
+++ b/NEWS
@@ -17,6 +17,10 @@ Post-v3.1.0
in order to create OVSDB sockets with access mode of 0770.
- QoS:
* Added new configuration option 'jitter' for a linux-netem QoS type.
+ - OVSDB:
+ * New unixctl command 'ovsdb-server/show-memory-trim-on-compaction'.
+ This command shows current value for memory trimming setting for
+ OVSDB server.
v3.1.0 - 16 Feb 2023
diff --git a/ovsdb/ovsdb-server.c b/ovsdb/ovsdb-server.c
index 33ca4910d..1994c0fdc 100644
--- a/ovsdb/ovsdb-server.c
+++ b/ovsdb/ovsdb-server.c
@@ -85,6 +85,7 @@ static bool trim_memory = true;
static unixctl_cb_func ovsdb_server_exit;
static unixctl_cb_func ovsdb_server_compact;
static unixctl_cb_func ovsdb_server_memory_trim_on_compaction;
+static unixctl_cb_func ovsdb_server_show_memory_trim_on_compaction;
static unixctl_cb_func ovsdb_server_reconnect;
static unixctl_cb_func ovsdb_server_perf_counters_clear;
static unixctl_cb_func ovsdb_server_perf_counters_show;
@@ -433,6 +434,9 @@ main(int argc, char *argv[])
unixctl_command_register("ovsdb-server/memory-trim-on-compaction",
"on|off", 1, 1,
ovsdb_server_memory_trim_on_compaction, NULL);
+unixctl_command_register("ovsdb-server/show-memory-trim-on-compaction", "",
+ 0, 0, ovsdb_server_show_memory_trim_on_compaction,
+ NULL);
unixctl_command_register("ovsdb-server/reconnect", "", 0, 0,
ovsdb_server_reconnect, jsonrpc);
@@ -1625,6 +1629,30 @@ ovsdb_server_memory_trim_on_compaction(struct
unixctl_conn *conn,
unixctl_command_reply(conn, NULL);
}
+/* "ovsdb-server/show-memory-trim-on-compaction": shows whether ovsdb-server
+ * memory-trim-on-compaction setting is enabled or not. */
+static void
+ovsdb_server_show_memory_trim_on_compaction(struct unixctl_conn *conn,
+int argc OVS_UNUSED,
+const char *argv[] OVS_UNUSED,
+void *arg OVS_UNUSED)
+{
+#if !HAVE_DECL_MALLOC_TRIM
+unixctl_command_reply_error(conn, "memory trimming is not supported");
+return;
+#endif
+
+struct ds s;
+
+ds_init(&s);
+ds_put_format(&s, "memory trim on compaction is %s",
+ trim_memory ? "enabled" : "disabled");
+
+unixctl_command_reply(conn, ds_cstr(&s));
+
+ds_destroy(&s);
+}
+
/* "ovsdb-server/reconnect": makes ovsdb-server drop all of its JSON-RPC
* connections and reconnect. */
static void
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 7/6] utilities: disable OVSDB inactivity probes for non-daemon ovn-nbctl
For large OVN_Southbound DBs default interval of 5000 ms could be not
sufficient. This patch disables OVSDB inactivity probes for ovn-{n,s}ctl
running
in non-daemon mode.
Signed-off-by: Vladislav Odintsov
---
utilities/ovn-dbctl.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/utilities/ovn-dbctl.c b/utilities/ovn-dbctl.c
index 369a6a663..4307a5cae 100644
--- a/utilities/ovn-dbctl.c
+++ b/utilities/ovn-dbctl.c
@@ -208,6 +208,9 @@ ovn_dbctl_main(int argc, char *argv[],
if (daemon_mode) {
server_loop(dbctl_options, idl, argc, argv_);
} else {
+/* Disable OVSDB probe interval for non-daemon mode. */
+ovsdb_idl_set_probe_interval(idl, 0);
+
struct ctl_command *commands;
size_t n_commands;
char *error;
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn 1/6] controller, northd: move inactivity probe configuration to lib/
Signed-off-by: Vladislav Odintsov
> On 19 Mar 2023, at 02:50, Vladislav Odintsov wrote:
>
> ovn-northd and ovn-controller had similar code to configure inactivity
> probe interval. This patch moves common logic to lib/ovn-util module.
> ---
> controller/ovn-controller.c | 8 ++--
> lib/ovn-util.c | 22 ++
> lib/ovn-util.h | 4
> northd/ovn-northd.c | 30 +-
> 4 files changed, 33 insertions(+), 31 deletions(-)
>
> diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
> index 7dcbfd252..2c09551cf 100644
> --- a/controller/ovn-controller.c
> +++ b/controller/ovn-controller.c
> @@ -104,7 +104,6 @@ static unixctl_cb_func debug_ignore_startup_delay;
>
> #define DEFAULT_BRIDGE_NAME "br-int"
> #define DEFAULT_DATAPATH "system"
> -#define DEFAULT_PROBE_INTERVAL_MSEC 5000
> #define OFCTRL_DEFAULT_PROBE_INTERVAL_SEC 0
>
> #define CONTROLLER_LOOP_STOPWATCH_NAME "flow-generation"
> @@ -595,13 +594,10 @@ update_sb_db(struct ovsdb_idl *ovs_idl, struct
> ovsdb_idl *ovnsb_idl,
> ovsdb_idl_set_remote(ovnsb_idl, remote, true);
>
> /* Set probe interval, based on user configuration and the remote. */
> -int default_interval = (remote && !stream_or_pstream_needs_probes(remote)
> -? 0 : DEFAULT_PROBE_INTERVAL_MSEC);
> int interval =
> get_chassis_external_id_value_int(
> -&cfg->external_ids, chassis_id,
> -"ovn-remote-probe-interval", default_interval);
> -ovsdb_idl_set_probe_interval(ovnsb_idl, interval);
> +&cfg->external_ids, chassis_id, "ovn-remote-probe-interval", -1);
> +set_idl_probe_interval(ovnsb_idl, remote, interval);
>
> bool monitor_all =
> get_chassis_external_id_value_bool(
> diff --git a/lib/ovn-util.c b/lib/ovn-util.c
> index 561e82093..13ae0dcce 100644
> --- a/lib/ovn-util.c
> +++ b/lib/ovn-util.c
> @@ -27,12 +27,16 @@
> #include "ovn-dirs.h"
> #include "ovn-nb-idl.h"
> #include "ovn-sb-idl.h"
> +#include "ovsdb-idl.h"
> #include "socket-util.h"
> +#include "stream.h"
> #include "svec.h"
> #include "unixctl.h"
>
> VLOG_DEFINE_THIS_MODULE(ovn_util);
>
> +#define DEFAULT_PROBE_INTERVAL_MSEC 5000
> +
> void ovn_conn_show(struct unixctl_conn *conn, int argc OVS_UNUSED,
>const char *argv[] OVS_UNUSED, void *idl_)
> {
> @@ -43,6 +47,24 @@ void ovn_conn_show(struct unixctl_conn *conn, int argc
> OVS_UNUSED,
> ovsdb_idl_is_connected(idl) ? "connected": "not connected");
> }
>
> +/* Set inactivity probe interval for 'idl' and 'remote' to 'interval'.
> + * If 'interval' < 0 (no preference from daemon settings), set it to 5000ms;
> + * if 'remote' needs probing, disable otherwise.
> + * 'interval' value of 0 disables probing.
> + */
> +void set_idl_probe_interval(struct ovsdb_idl *idl, const char *remote,
> +int interval)
> +{
> +if (interval < 0) {
> +interval = (remote && !stream_or_pstream_needs_probes(remote)
> +? 0 : DEFAULT_PROBE_INTERVAL_MSEC);
> +} else if (interval > 0 && interval < 1000) {
> +interval = 1000;
> +}
> +
> +ovsdb_idl_set_probe_interval(idl, interval);
> +}
> +
> static void
> add_ipv4_netaddr(struct lport_addresses *laddrs, ovs_be32 addr,
> unsigned int plen)
> diff --git a/lib/ovn-util.h b/lib/ovn-util.h
> index a1a418a24..7cf861dbc 100644
> --- a/lib/ovn-util.h
> +++ b/lib/ovn-util.h
> @@ -16,6 +16,7 @@
> #ifndef OVN_UTIL_H
> #define OVN_UTIL_H 1
>
> +#include "ovsdb-idl.h"
> #include "lib/packets.h"
> #include "include/ovn/version.h"
>
> @@ -140,6 +141,9 @@ uint32_t ovn_logical_flow_hash_datapath(const struct uuid
> *logical_datapath,
> void ovn_conn_show(struct unixctl_conn *conn, int argc OVS_UNUSED,
>const char *argv[] OVS_UNUSED, void *idl_);
>
> +void set_idl_probe_interval(struct ovsdb_idl *idl, const char *remote,
> +int interval);
> +
> #define OVN_MAX_DP_KEY ((1u << 24) - 1)
> #define OVN_MAX_DP_GLOBAL_NUM ((1u << 16) - 1)
> #define OVN_MIN_DP_KEY_LOCAL 1
> diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> index 5f895b053..116b6e801 100644
> --- a/northd/ovn-northd.c
> +++ b/northd/ovn-northd.c
> @@ -71,11 +71,6 @@ stati
[ovs-dev] [PATCH ovn 4/6] controller-vtep: add unixctl commands to show DB connection status
New unixctl commands were added:
- sb-connection-status
- vtep-connection-status
Signed-off-by: Vladislav Odintsov
---
controller-vtep/ovn-controller-vtep.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/controller-vtep/ovn-controller-vtep.c
b/controller-vtep/ovn-controller-vtep.c
index 8023bb869..5f017d87d 100644
--- a/controller-vtep/ovn-controller-vtep.c
+++ b/controller-vtep/ovn-controller-vtep.c
@@ -175,6 +175,11 @@ main(int argc, char *argv[])
char *ovn_version = ovn_get_internal_version();
VLOG_INFO("OVN internal version is : [%s]", ovn_version);
+unixctl_command_register("sb-connection-status", "", 0, 0,
+ ovn_conn_show, ovnsb_idl_loop.idl);
+unixctl_command_register("vtep-connection-status", "", 0, 0,
+ ovn_conn_show, vtep_idl_loop.idl);
+
/* Main loop. */
exiting = false;
while (!exiting) {
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 6/6] NEWS: add info about ic/controller-vtep inactivity probe support
Signed-off-by: Vladislav Odintsov --- NEWS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/NEWS b/NEWS index 637adcff3..fc1b68324 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,8 @@ Post v23.03.0 - - Enhance LSP.options:arp_proxy to support IPv6, configurable MAC addresses and CIDRs. + - Add support to configure OVSDB inactivity probe interval for ovn-ic and +ovn-controller-vtep. OVN v23.03.0 - 03 Mar 2023 -- -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 5/6] ovn-ic: add unixctl commands to report db connection status
New unixctl commands were added:
- nb-connection-status
- sb-connection-status
- ic-nb-connection-status
- ic-sb-connection-status
Signed-off-by: Vladislav Odintsov
---
ic/ovn-ic.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
index feb100859..6f31037ec 100644
--- a/ic/ovn-ic.c
+++ b/ic/ovn-ic.c
@@ -2091,6 +2091,15 @@ main(int argc, char *argv[])
&icsbrec_route_col_transit_switch,
&icsbrec_route_col_availability_zone);
+unixctl_command_register("nb-connection-status", "", 0, 0,
+ ovn_conn_show, ovnnb_idl_loop.idl);
+unixctl_command_register("sb-connection-status", "", 0, 0,
+ ovn_conn_show, ovnsb_idl_loop.idl);
+unixctl_command_register("ic-nb-connection-status", "", 0, 0,
+ ovn_conn_show, ovninb_idl_loop.idl);
+unixctl_command_register("ic-sb-connection-status", "", 0, 0,
+ ovn_conn_show, ovnisb_idl_loop.idl);
+
/* Main loop. */
exiting = false;
state.had_lock = false;
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 3/6] controller-vtep: add support to configure inactivity probe interval
This patch adds new configuration option for ovn-controller-vtep service
to supply OVSDB (only OVN_Southbound DB) probe interval value.
It can be configured through Hardware_Vtep database, Global table, column
other_config:ovn-remote-probe-interval.
Signed-off-by: Vladislav Odintsov
---
controller-vtep/ovn-controller-vtep.8.xml | 14 ++
controller-vtep/ovn-controller-vtep.c | 17 +
2 files changed, 31 insertions(+)
diff --git a/controller-vtep/ovn-controller-vtep.8.xml
b/controller-vtep/ovn-controller-vtep.8.xml
index 0b9987bdb..89acae7ed 100644
--- a/controller-vtep/ovn-controller-vtep.8.xml
+++ b/controller-vtep/ovn-controller-vtep.8.xml
@@ -96,6 +96,20 @@
connected hardware_vtep database changes.
The default value is considered false if this option is not defined.
+
+ other_config:ovn-remote-probe-interval
+
+
+ The inactivity probe interval of the connection to the OVN Southbound
+ database, in milliseconds. If the value is zero, it disables the
+ connection keepalive feature.
+
+
+
+ If the value is nonzero, then it will be forced to a value of at
+ least 1000 ms.
+
+
diff --git a/controller-vtep/ovn-controller-vtep.c
b/controller-vtep/ovn-controller-vtep.c
index 26f8fd115..8023bb869 100644
--- a/controller-vtep/ovn-controller-vtep.c
+++ b/controller-vtep/ovn-controller-vtep.c
@@ -31,6 +31,7 @@
#include "openvswitch/poll-loop.h"
#include "simap.h"
#include "ovsdb-idl.h"
+#include "smap.h"
#include "stream.h"
#include "stream-ssl.h"
#include "unixctl.h"
@@ -88,6 +89,20 @@ check_northd_version(struct ovsdb_idl *vtep_idl, struct
ovsdb_idl *ovnsb_idl,
return true;
}
+/* Set probe interval, based on user configuration and the remote. */
+static void
+update_idl_probe_interval(struct ovsdb_idl *ovn_sb_idl,
+ struct ovsdb_idl *vtep_idl)
+{
+const struct vteprec_global *cfg = vteprec_global_first(vtep_idl);
+int interval = -1;
+if (cfg) {
+interval = smap_get_int(&cfg->other_config,
+"ovn-remote-probe-interval", interval);
+}
+set_idl_probe_interval(ovn_sb_idl, ovnsb_remote, interval);
+}
+
int
main(int argc, char *argv[])
{
@@ -179,6 +194,8 @@ main(int argc, char *argv[])
simap_destroy(&usage);
}
+update_idl_probe_interval(ovnsb_idl_loop.idl, vtep_idl_loop.idl);
+
if (ovsdb_idl_has_ever_connected(ovnsb_idl_loop.idl) &&
ovsdb_idl_has_ever_connected(vtep_idl_loop.idl) &&
check_northd_version(vtep_idl_loop.idl, ovnsb_idl_loop.idl,
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 2/6] ic: add support to configure ovsdb inactivity probe
IDL to local AZ DBs (OVN_Northbound, OVN_Southbound) should be configured
in NB DB, table NB_Global, column options:ic_probe_interval.
IDL to global DBs (OVN_IC_Northbound, OVN_IC_Southbound) should be
configured in IC NB DB, table IC_NB_Global, column
options:ic_probe_interval.
Signed-off-by: Vladislav Odintsov
---
ic/ovn-ic.c | 28
ovn-ic-nb.xml | 14 ++
ovn-nb.xml| 13 +
3 files changed, 55 insertions(+)
diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c
index 1d0a062f6..feb100859 100644
--- a/ic/ovn-ic.c
+++ b/ic/ovn-ic.c
@@ -35,6 +35,7 @@
#include "lib/ovn-util.h"
#include "memory.h"
#include "openvswitch/poll-loop.h"
+#include "ovsdb-idl.h"
#include "simap.h"
#include "smap.h"
#include "sset.h"
@@ -1871,6 +1872,31 @@ update_ssl_config(void)
}
}
+static void
+update_idl_probe_interval(struct ovsdb_idl *ovn_sb_idl,
+ struct ovsdb_idl *ovn_nb_idl,
+ struct ovsdb_idl *ovn_icsb_idl,
+ struct ovsdb_idl *ovn_icnb_idl)
+{
+const struct nbrec_nb_global *nb = nbrec_nb_global_first(ovn_nb_idl);
+int interval = -1;
+if (nb) {
+interval = smap_get_int(&nb->options, "ic_probe_interval", interval);
+}
+set_idl_probe_interval(ovn_sb_idl, ovnsb_db, interval);
+set_idl_probe_interval(ovn_nb_idl, ovnnb_db, interval);
+
+const struct icnbrec_ic_nb_global *icnb =
+icnbrec_ic_nb_global_first(ovn_icnb_idl);
+int ic_interval = -1;
+if (icnb) {
+ic_interval = smap_get_int(&icnb->options, "ic_probe_interval",
+ ic_interval);
+}
+set_idl_probe_interval(ovn_icsb_idl, ovn_ic_sb_db, ic_interval);
+set_idl_probe_interval(ovn_icnb_idl, ovn_ic_nb_db, ic_interval);
+}
+
int
main(int argc, char *argv[])
{
@@ -2071,6 +2097,8 @@ main(int argc, char *argv[])
state.paused = false;
while (!exiting) {
update_ssl_config();
+update_idl_probe_interval(ovnsb_idl_loop.idl, ovnnb_idl_loop.idl,
+ ovnisb_idl_loop.idl, ovninb_idl_loop.idl);
memory_run();
if (memory_should_report()) {
struct simap usage = SIMAP_INITIALIZER(&usage);
diff --git a/ovn-ic-nb.xml b/ovn-ic-nb.xml
index a693611c3..8c53bec3b 100644
--- a/ovn-ic-nb.xml
+++ b/ovn-ic-nb.xml
@@ -47,6 +47,20 @@
This column provides general key/value settings. The supported
options are described individually below.
+
+
+
+ The inactivity probe interval of the connection to the OVN IC
+ Northbound and Southbound databases from ovn-ic, in
+ milliseconds. If the value is zero, it disables the connection
+ keepalive feature.
+
+
+
+ If the value is nonzero, then it will be forced to a value of
+ at least 1000 ms.
+
+
diff --git a/ovn-nb.xml b/ovn-nb.xml
index 73f707aa0..fd32070f2 100644
--- a/ovn-nb.xml
+++ b/ovn-nb.xml
@@ -202,6 +202,19 @@
+
+
+ The inactivity probe interval of the connection to the OVN Northbound
+ and Southbound databases from ovn-ic, in milliseconds.
+ If the value is zero, it disables the connection keepalive feature.
+
+
+
+ If the value is nonzero, then it will be forced to a value of
+ at least 1000 ms.
+
+
+
When used, this configuration value specifies the time, in
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn 1/6] controller, northd: move inactivity probe configuration to lib/
ovn-northd and ovn-controller had similar code to configure inactivity
probe interval. This patch moves common logic to lib/ovn-util module.
---
controller/ovn-controller.c | 8 ++--
lib/ovn-util.c | 22 ++
lib/ovn-util.h | 4
northd/ovn-northd.c | 30 +-
4 files changed, 33 insertions(+), 31 deletions(-)
diff --git a/controller/ovn-controller.c b/controller/ovn-controller.c
index 7dcbfd252..2c09551cf 100644
--- a/controller/ovn-controller.c
+++ b/controller/ovn-controller.c
@@ -104,7 +104,6 @@ static unixctl_cb_func debug_ignore_startup_delay;
#define DEFAULT_BRIDGE_NAME "br-int"
#define DEFAULT_DATAPATH "system"
-#define DEFAULT_PROBE_INTERVAL_MSEC 5000
#define OFCTRL_DEFAULT_PROBE_INTERVAL_SEC 0
#define CONTROLLER_LOOP_STOPWATCH_NAME "flow-generation"
@@ -595,13 +594,10 @@ update_sb_db(struct ovsdb_idl *ovs_idl, struct ovsdb_idl
*ovnsb_idl,
ovsdb_idl_set_remote(ovnsb_idl, remote, true);
/* Set probe interval, based on user configuration and the remote. */
-int default_interval = (remote && !stream_or_pstream_needs_probes(remote)
-? 0 : DEFAULT_PROBE_INTERVAL_MSEC);
int interval =
get_chassis_external_id_value_int(
-&cfg->external_ids, chassis_id,
-"ovn-remote-probe-interval", default_interval);
-ovsdb_idl_set_probe_interval(ovnsb_idl, interval);
+&cfg->external_ids, chassis_id, "ovn-remote-probe-interval", -1);
+set_idl_probe_interval(ovnsb_idl, remote, interval);
bool monitor_all =
get_chassis_external_id_value_bool(
diff --git a/lib/ovn-util.c b/lib/ovn-util.c
index 561e82093..13ae0dcce 100644
--- a/lib/ovn-util.c
+++ b/lib/ovn-util.c
@@ -27,12 +27,16 @@
#include "ovn-dirs.h"
#include "ovn-nb-idl.h"
#include "ovn-sb-idl.h"
+#include "ovsdb-idl.h"
#include "socket-util.h"
+#include "stream.h"
#include "svec.h"
#include "unixctl.h"
VLOG_DEFINE_THIS_MODULE(ovn_util);
+#define DEFAULT_PROBE_INTERVAL_MSEC 5000
+
void ovn_conn_show(struct unixctl_conn *conn, int argc OVS_UNUSED,
const char *argv[] OVS_UNUSED, void *idl_)
{
@@ -43,6 +47,24 @@ void ovn_conn_show(struct unixctl_conn *conn, int argc
OVS_UNUSED,
ovsdb_idl_is_connected(idl) ? "connected": "not connected");
}
+/* Set inactivity probe interval for 'idl' and 'remote' to 'interval'.
+ * If 'interval' < 0 (no preference from daemon settings), set it to 5000ms;
+ * if 'remote' needs probing, disable otherwise.
+ * 'interval' value of 0 disables probing.
+ */
+void set_idl_probe_interval(struct ovsdb_idl *idl, const char *remote,
+int interval)
+{
+if (interval < 0) {
+interval = (remote && !stream_or_pstream_needs_probes(remote)
+? 0 : DEFAULT_PROBE_INTERVAL_MSEC);
+} else if (interval > 0 && interval < 1000) {
+interval = 1000;
+}
+
+ovsdb_idl_set_probe_interval(idl, interval);
+}
+
static void
add_ipv4_netaddr(struct lport_addresses *laddrs, ovs_be32 addr,
unsigned int plen)
diff --git a/lib/ovn-util.h b/lib/ovn-util.h
index a1a418a24..7cf861dbc 100644
--- a/lib/ovn-util.h
+++ b/lib/ovn-util.h
@@ -16,6 +16,7 @@
#ifndef OVN_UTIL_H
#define OVN_UTIL_H 1
+#include "ovsdb-idl.h"
#include "lib/packets.h"
#include "include/ovn/version.h"
@@ -140,6 +141,9 @@ uint32_t ovn_logical_flow_hash_datapath(const struct uuid
*logical_datapath,
void ovn_conn_show(struct unixctl_conn *conn, int argc OVS_UNUSED,
const char *argv[] OVS_UNUSED, void *idl_);
+void set_idl_probe_interval(struct ovsdb_idl *idl, const char *remote,
+int interval);
+
#define OVN_MAX_DP_KEY ((1u << 24) - 1)
#define OVN_MAX_DP_GLOBAL_NUM ((1u << 16) - 1)
#define OVN_MIN_DP_KEY_LOCAL 1
diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index 5f895b053..116b6e801 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -71,11 +71,6 @@ static const char *ssl_private_key_file;
static const char *ssl_certificate_file;
static const char *ssl_ca_cert_file;
-/* Default probe interval for NB and SB DB connections. */
-#define DEFAULT_PROBE_INTERVAL_MSEC 5000
-static int northd_probe_interval_nb = 0;
-static int northd_probe_interval_sb = 0;
-
static const char *rbac_chassis_auth[] =
{"name"};
static const char *rbac_chassis_update[] =
@@ -684,20 +679,6 @@ update_ssl_config(void)
}
}
-static int
-get_probe_interval(const char *db, const struct nbrec_nb_global *nb)
-{
-int default_interval = (db && !stream_or_pstream_needs_probes(db)
-? 0 : DEFAULT_PROBE_INTERVAL_MSEC);
-int interval = smap_get_int(&nb->options,
-"northd_probe_interval", default_interval);
-
-if (interval > 0 && interval < 1000) {
-interval = 1000;
-}
-return interval;
-}
-
static struct ovsdb_idl_txn
[ovs-dev] [PATCH ovn 0/6] Inactivity probe configuration for ic, controller-vtep
This patch series adds support to configure inactivity probe for ovn-ic and ovn-controller-vtep. In first commit is just a preparation for adding support: the duplicated logic from ovn-controller and ovn-northd is moved to lib/ovn-util. Additionally methods to monitor OVSDB connection status were added to ovn-ic and ovn-controller-vtep. Vladislav Odintsov (6): controller,northd: move inactivity probe configuration to lib/ ic: add support to configure ovsdb inactivity probe controller-vtep: add support to configure inactivity probe interval controller-vtep: add unixctl commands to show DB connection status ovn-ic: add unixctl commands to report db connection status NEWS: add info about ic/controller-vtep inactivity probe support NEWS | 2 ++ controller-vtep/ovn-controller-vtep.8.xml | 14 + controller-vtep/ovn-controller-vtep.c | 22 ++ controller/ovn-controller.c | 8 ++--- ic/ovn-ic.c | 37 +++ lib/ovn-util.c| 22 ++ lib/ovn-util.h| 4 +++ northd/ovn-northd.c | 30 +++--- ovn-ic-nb.xml | 14 + ovn-nb.xml| 13 10 files changed, 135 insertions(+), 31 deletions(-) -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn] rhel: pass options to stop daemon command in systemd units
Thanks Dumitru!
> On 8 Mar 2023, at 15:45, Dumitru Ceara wrote:
>
> On 3/7/23 10:19, Ales Musil wrote:
>> On Mon, Feb 27, 2023 at 7:41 PM Vladislav Odintsov
>> wrote:
>>
>>> This patch fixes ovn-northd.service and ovn-db@.service systemd units
>>> which didn't pass startup options to ovn-ctl script while stop_* call.
>>>
>>> For instance if ovn-northd service was started with option
>>> '--ovn-manage-ovsdb=no' and NB/SB databases are located on the same host
>>> and started by ovn-db@nb / ovn-db@sb or manually with ovn-ctl, so
>>> ovsdb-server processes for these services will be unexpectedly stopped.
>>>
>>> Fixes: 497ec3fdfbdb ("rhel: add ovn-db@.service systemd-unit")
>>> Signed-off-by: Vladislav Odintsov
>>> ---
>
> [...]
>
>> Looks good to me, thanks.
>>
>> Acked-by: Ales Musil
>>
>
> Thanks, Vladislav and Ales!
>
> I applied this to the main branch and backported it to 23.03.
>
> Regards,
> Dumitru
>
Regards,
Vladislav Odintsov
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn] rhel: pass options to stop daemon command in systemd units
This patch fixes ovn-northd.service and ovn-db@.service systemd units
which didn't pass startup options to ovn-ctl script while stop_* call.
For instance if ovn-northd service was started with option
'--ovn-manage-ovsdb=no' and NB/SB databases are located on the same host
and started by ovn-db@nb / ovn-db@sb or manually with ovn-ctl, so
ovsdb-server processes for these services will be unexpectedly stopped.
Fixes: 497ec3fdfbdb ("rhel: add ovn-db@.service systemd-unit")
Signed-off-by: Vladislav Odintsov
---
rhel/usr_lib_systemd_system_ovn-db@.service| 2 +-
rhel/usr_lib_systemd_system_ovn-northd.service | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/rhel/usr_lib_systemd_system_ovn-db@.service
b/rhel/usr_lib_systemd_system_ovn-db@.service
index 98556a673..c835e4967 100644
--- a/rhel/usr_lib_systemd_system_ovn-db@.service
+++ b/rhel/usr_lib_systemd_system_ovn-db@.service
@@ -33,7 +33,7 @@ EnvironmentFile=-/etc/sysconfig/ovn-%i
ExecStartPre=-/usr/bin/chown -R ${OVN_USER_ID} ${OVN_DBDIR}
ExecStart=/usr/share/ovn/scripts/ovn-ctl \
--ovn-user=${OVN_USER_ID} start_%i_ovsdb $OPTIONS $ovn_%i_opts
-ExecStop=/usr/share/ovn/scripts/ovn-ctl stop_%i_ovsdb
+ExecStop=/usr/share/ovn/scripts/ovn-ctl stop_%i_ovsdb $OPTIONS $ovn_%i_opts
[Install]
WantedBy=multi-user.target
diff --git a/rhel/usr_lib_systemd_system_ovn-northd.service
b/rhel/usr_lib_systemd_system_ovn-northd.service
index d281f861c..6c4c6621c 100644
--- a/rhel/usr_lib_systemd_system_ovn-northd.service
+++ b/rhel/usr_lib_systemd_system_ovn-northd.service
@@ -26,7 +26,7 @@ EnvironmentFile=-/etc/sysconfig/ovn-northd
ExecStartPre=-/usr/bin/chown -R ${OVN_USER_ID} ${OVN_DBDIR}
ExecStart=/usr/share/ovn/scripts/ovn-ctl \
--ovn-user=${OVN_USER_ID} start_northd $OVN_NORTHD_OPTS
-ExecStop=/usr/share/ovn/scripts/ovn-ctl stop_northd
+ExecStop=/usr/share/ovn/scripts/ovn-ctl stop_northd $OVN_NORTHD_OPTS
[Install]
WantedBy=multi-user.target
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3] utilities: add support to set umask in ovs-ctl
Thanks, Ilya! > On 20 Feb 2023, at 22:21, Ilya Maximets wrote: > > On 2/15/23 22:20, Vladislav Odintsov wrote: >> Hi Ilya, >> >> Thats my bad - they were the initial names of options, which I renamed later >> and missed this place before sending a patch. >> I’m absolutely fine with proposed change. Please fold it while applying the >> patch. > > Thanks, Vladislav and Eelco! > I updated the NEWS and applied the change. > > Best regards, Ilya Maximets. > >> >> Thanks. >> >> regards, >> Vladislav Odintsov >> >>> On 15 Feb 2023, at 22:25, Ilya Maximets wrote: >>> >>> On 2/10/23 17:02, Vladislav Odintsov wrote: >>>> This patch adds new ovs-ctl options to pass umask configuration to allow >>>> OVS daemons set requested socket permissions on group. Previous >>>> behaviour (if using with systemd service unit) created sockets with 0750 >>>> permissions mask (group has no write permission). >>>> >>>> Write permission for group is reasonable in usecase, where ovs-vswitchd >>>> or ovsdb-server runs as a non-privileged user:group (say, >>>> openvswitch:openvswitch) and it is needed to access unix socket from >>>> process running as another non-privileged user. In this case >>>> administrator has to add that user to openvswitch group and can connect >>>> to OVS sockets from a process running under that user. >>>> >>>> Two new ovs-ctl options --ovsdb-server-umask and --ovs-vswitchd-umask >>>> were added to manage umask values for appropriate daemons. This is >>>> useful for systemd users: both ovs-vswitchd and ovsdb-server systemd >>>> units read options from single /etc/sysconfig/openvswitch configuration >>>> file. So, with separate options it is possible to set umask only for >>>> specific daemon. >>>> >>>> OPTIONS="--ovsdb-server-umask=0002" >>>> >>>> in /etc/openvswitch/sysconfig file will set umask to 0002 value before >>>> starting only ovsdb-server, while >>>> >>>> OPTIONS="--ovs-vswitchd-umask=0002" >>>> >>>> will set umask to ovs-vswitchd daemon. >>>> >>>> Previous behaviour (not setting umask) is left as default. >>>> >>>> Reported-at: >>>> https://mail.openvswitch.org/pipermail/ovs-dev/2023-January/401501.html >>>> Signed-off-by: Vladislav Odintsov >>>> >>>> --- >>>> v2 -> v3: >>>> - addressed Eelco's review comments. >>>> >>>> v1 -> v2: >>>> - added item in NEWS file as Ilya's suggestion; >>>> - addressed Eelco's review comments; >>>> - moved umask call from ovs-ctl to ovs-lib; >>>> - added restoration of umask to effective value before the umask change; >>>> - previous version --ovs-umask option was split into two: >>>> --ovs-vswitchd-umask and --ovsdb-server-umask in order to make >>>> possible umask configuration for specific daemon when running with >>>> systemd. >>>> --- >>>> NEWS | 7 +++ >>>> utilities/ovs-ctl.in | 16 >>>> utilities/ovs-lib.in | 17 ++--- >>>> 3 files changed, 33 insertions(+), 7 deletions(-) >>>> >>>> diff --git a/NEWS b/NEWS >>>> index fe6055a27..f7df598bd 100644 >>>> --- a/NEWS >>>> +++ b/NEWS >>>> @@ -4,6 +4,13 @@ Post-v3.1.0 >>>> * OVS now collects per-interface upcall statistics that can be obtained >>>> via 'ovs-appctl dpctl/show -s' or the interface's statistics column >>>> in OVSDB. Available with upstream kernel 6.2+. >>>> + - ovs-ctl: >>>> + * Added support to set umask value when starting OVS daemons. New >>>> options >>>> + --ovsdb-server-umask=MODE and --ovs-vswitchd-umask=MODE were added >>>> for >>>> + that. For instance, when write access on befalf of OVS group is >>>> needed >>>> + for ovsdb-server, pass --ovsdb-umask=0002. Use --vswitchd-umask >>>> to set >>>> + umask ovs-vswitchd daemon umask. This will allow ovsdb-server or >>>> + ovs-vswitchd to create sockets with access mode of 0770. >>> >>> The options in the example are incorrect. >>> Also, the text seems slightly too extensive. >>> >>> What do you think about this: >>> >>> - ovs-ctl: >>>* Added new options --[ovsdb-server|ovs-vswitchd]-umask=MODE to set umask >>> value when starting OVS daemons. E.g., use --ovsdb-server-umask=0002 >>> in order to create OVSDB sockets with access mode of 0770. >>> >>> ? >>> >>> I could fold this in while applying the change. >>> >>> Best regards, Ilya Maximets. > > ___ > dev mailing list > d...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v3] utilities: add support to set umask in ovs-ctl
Hi Ilya, Thats my bad - they were the initial names of options, which I renamed later and missed this place before sending a patch. I’m absolutely fine with proposed change. Please fold it while applying the patch. Thanks. regards, Vladislav Odintsov > On 15 Feb 2023, at 22:25, Ilya Maximets wrote: > > On 2/10/23 17:02, Vladislav Odintsov wrote: >> This patch adds new ovs-ctl options to pass umask configuration to allow >> OVS daemons set requested socket permissions on group. Previous >> behaviour (if using with systemd service unit) created sockets with 0750 >> permissions mask (group has no write permission). >> >> Write permission for group is reasonable in usecase, where ovs-vswitchd >> or ovsdb-server runs as a non-privileged user:group (say, >> openvswitch:openvswitch) and it is needed to access unix socket from >> process running as another non-privileged user. In this case >> administrator has to add that user to openvswitch group and can connect >> to OVS sockets from a process running under that user. >> >> Two new ovs-ctl options --ovsdb-server-umask and --ovs-vswitchd-umask >> were added to manage umask values for appropriate daemons. This is >> useful for systemd users: both ovs-vswitchd and ovsdb-server systemd >> units read options from single /etc/sysconfig/openvswitch configuration >> file. So, with separate options it is possible to set umask only for >> specific daemon. >> >> OPTIONS="--ovsdb-server-umask=0002" >> >> in /etc/openvswitch/sysconfig file will set umask to 0002 value before >> starting only ovsdb-server, while >> >> OPTIONS="--ovs-vswitchd-umask=0002" >> >> will set umask to ovs-vswitchd daemon. >> >> Previous behaviour (not setting umask) is left as default. >> >> Reported-at: >> https://mail.openvswitch.org/pipermail/ovs-dev/2023-January/401501.html >> Signed-off-by: Vladislav Odintsov >> >> --- >> v2 -> v3: >> - addressed Eelco's review comments. >> >> v1 -> v2: >> - added item in NEWS file as Ilya's suggestion; >> - addressed Eelco's review comments; >> - moved umask call from ovs-ctl to ovs-lib; >> - added restoration of umask to effective value before the umask change; >> - previous version --ovs-umask option was split into two: >>--ovs-vswitchd-umask and --ovsdb-server-umask in order to make >>possible umask configuration for specific daemon when running with >>systemd. >> --- >> NEWS | 7 +++ >> utilities/ovs-ctl.in | 16 >> utilities/ovs-lib.in | 17 ++--- >> 3 files changed, 33 insertions(+), 7 deletions(-) >> >> diff --git a/NEWS b/NEWS >> index fe6055a27..f7df598bd 100644 >> --- a/NEWS >> +++ b/NEWS >> @@ -4,6 +4,13 @@ Post-v3.1.0 >> * OVS now collects per-interface upcall statistics that can be obtained >>via 'ovs-appctl dpctl/show -s' or the interface's statistics column >>in OVSDB. Available with upstream kernel 6.2+. >> + - ovs-ctl: >> + * Added support to set umask value when starting OVS daemons. New >> options >> + --ovsdb-server-umask=MODE and --ovs-vswitchd-umask=MODE were added >> for >> + that. For instance, when write access on befalf of OVS group is >> needed >> + for ovsdb-server, pass --ovsdb-umask=0002. Use --vswitchd-umask to >> set >> + umask ovs-vswitchd daemon umask. This will allow ovsdb-server or >> + ovs-vswitchd to create sockets with access mode of 0770. > > The options in the example are incorrect. > Also, the text seems slightly too extensive. > > What do you think about this: > > - ovs-ctl: > * Added new options --[ovsdb-server|ovs-vswitchd]-umask=MODE to set umask > value when starting OVS daemons. E.g., use --ovsdb-server-umask=0002 > in order to create OVSDB sockets with access mode of 0770. > > ? > > I could fold this in while applying the change. > > Best regards, Ilya Maximets. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v2] utilities: add support to set umask in ovs-ctl
Thanks Eelco,
requested changes addressed here:
https://patchwork.ozlabs.org/project/openvswitch/patch/20230210160229.3689298-1-odiv...@gmail.com/
> On 10 Feb 2023, at 11:21, Eelco Chaudron wrote:
>
>
>
> On 8 Feb 2023, at 16:22, Vladislav Odintsov wrote:
>
>> This patch adds new ovs-ctl options to pass umask configuration to allow
>> OVS daemons set requested socket permissions on group. Previous
>> behaviour (if using with systemd service unit) created sockets with 0750
>> permissions mask (group has no write permission).
>>
>> Write permission for group is reasonable in usecase, where ovs-vswitchd
>> or ovsdb-server runs as a non-privileged user:group (say,
>> openvswitch:openvswitch) and it is needed to access unix socket from
>> process running as another non-privileged user. In this case
>> administrator has to add that user to openvswitch group and can connect
>> to OVS sockets from a process running under that user.
>>
>> Two new ovs-ctl options --ovsdb-server-umask and --ovs-vswitchd-umask
>> were added to manage umask values for appropriate daemons. This is
>> useful for systemd users: both ovs-vswitchd and ovsdb-server systemd
>> units read options from single /etc/sysconfig/openvswitch configuration
>> file. So, with separate options it is possible to set umask only for
>> specific daemon.
>>
>> OPTIONS="--ovsdb-server-umask=0002"
>>
>> in /etc/openvswitch/sysconfig file will set umask to 0002 value before
>> starting only ovsdb-server, while
>>
>> OPTIONS="--ovs-vswitchd-umask=0002"
>>
>> will set umask to ovs-vswitchd daemon.
>>
>> Previous behaviour (not setting umask) is left as default.
>
> Thanks for reworking the patch, small none technical nit below, the rest
> looks good.
>
> //Eelco
>
>
>> Reported-at:
>> https://mail.openvswitch.org/pipermail/ovs-dev/2023-January/401501.html
>> Signed-off-by: Vladislav Odintsov
>>
>> ---
>> v1 -> v2:
>> - added item in NEWS file as Ilya's suggestion;
>> - addressed Eelco's review comments;
>> - moved umask call from ovs-ctl to ovs-lib;
>> - added restoration of umask to effective value before the umask change;
>> - previous version --ovs-umask option was split into two:
>>--ovs-vswitchd-umask and --ovsdb-server-umask in order to make
>>possible umask configuration for specific daemon when running with
>>systemd.
>>
>> Signed-off-by: Vladislav Odintsov
>> ---
>> NEWS | 7 +++
>> utilities/ovs-ctl.in | 16
>> utilities/ovs-lib.in | 17 ++---
>> 3 files changed, 33 insertions(+), 7 deletions(-)
>>
>> diff --git a/NEWS b/NEWS
>> index fe6055a27..f7df598bd 100644
>> --- a/NEWS
>> +++ b/NEWS
>> @@ -4,6 +4,13 @@ Post-v3.1.0
>> * OVS now collects per-interface upcall statistics that can be obtained
>>via 'ovs-appctl dpctl/show -s' or the interface's statistics column
>>in OVSDB. Available with upstream kernel 6.2+.
>> + - ovs-ctl:
>> + * Added support to set umask value when starting OVS daemons. New
>> options
>> + --ovsdb-server-umask=MODE and --ovs-vswitchd-umask=MODE were added
>> for
>> + that. For instance, when write access on befalf of OVS group is
>> needed
>> + for ovsdb-server, pass --ovsdb-umask=0002. Use --vswitchd-umask to
>> set
>> + umask ovs-vswitchd daemon umask. This will allow ovsdb-server or
>> + ovs-vswitchd to create sockets with access mode of 0770.
>>
>>
>> v3.1.0 - xx xxx
>> diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
>> index d91552588..0b2820c36 100644
>> --- a/utilities/ovs-ctl.in
>> +++ b/utilities/ovs-ctl.in
>> @@ -156,8 +156,8 @@ do_start_ovsdb () {
>> [ "$OVS_USER" != "" ] && set "$@" --user "$OVS_USER"
>> [ "$OVSDB_SERVER_OPTIONS" != "" ] && set "$@" $OVSDB_SERVER_OPTIONS
>>
>> -start_daemon "$OVSDB_SERVER_PRIORITY" "$OVSDB_SERVER_WRAPPER" "$@" \
>> -|| return 1
>> +start_daemon "$OVSDB_SERVER_PRIORITY" "$OVSDB_SERVER_WRAPPER" \
>> +"$OVSDB_SERVER_UMASK" "$@" || return 1
>>
>> # Initialize database settings.
>> ovs_vsctl -- init -- set Open_vSwitch . db-version="$schemaver" \
>> @@ -226,8 +
[ovs-dev] [PATCH v3] utilities: add support to set umask in ovs-ctl
This patch adds new ovs-ctl options to pass umask configuration to allow
OVS daemons set requested socket permissions on group. Previous
behaviour (if using with systemd service unit) created sockets with 0750
permissions mask (group has no write permission).
Write permission for group is reasonable in usecase, where ovs-vswitchd
or ovsdb-server runs as a non-privileged user:group (say,
openvswitch:openvswitch) and it is needed to access unix socket from
process running as another non-privileged user. In this case
administrator has to add that user to openvswitch group and can connect
to OVS sockets from a process running under that user.
Two new ovs-ctl options --ovsdb-server-umask and --ovs-vswitchd-umask
were added to manage umask values for appropriate daemons. This is
useful for systemd users: both ovs-vswitchd and ovsdb-server systemd
units read options from single /etc/sysconfig/openvswitch configuration
file. So, with separate options it is possible to set umask only for
specific daemon.
OPTIONS="--ovsdb-server-umask=0002"
in /etc/openvswitch/sysconfig file will set umask to 0002 value before
starting only ovsdb-server, while
OPTIONS="--ovs-vswitchd-umask=0002"
will set umask to ovs-vswitchd daemon.
Previous behaviour (not setting umask) is left as default.
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-dev/2023-January/401501.html
Signed-off-by: Vladislav Odintsov
---
v2 -> v3:
- addressed Eelco's review comments.
v1 -> v2:
- added item in NEWS file as Ilya's suggestion;
- addressed Eelco's review comments;
- moved umask call from ovs-ctl to ovs-lib;
- added restoration of umask to effective value before the umask change;
- previous version --ovs-umask option was split into two:
--ovs-vswitchd-umask and --ovsdb-server-umask in order to make
possible umask configuration for specific daemon when running with
systemd.
---
NEWS | 7 +++
utilities/ovs-ctl.in | 16
utilities/ovs-lib.in | 17 ++---
3 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/NEWS b/NEWS
index fe6055a27..f7df598bd 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,13 @@ Post-v3.1.0
* OVS now collects per-interface upcall statistics that can be obtained
via 'ovs-appctl dpctl/show -s' or the interface's statistics column
in OVSDB. Available with upstream kernel 6.2+.
+ - ovs-ctl:
+ * Added support to set umask value when starting OVS daemons. New options
+ --ovsdb-server-umask=MODE and --ovs-vswitchd-umask=MODE were added for
+ that. For instance, when write access on befalf of OVS group is needed
+ for ovsdb-server, pass --ovsdb-umask=0002. Use --vswitchd-umask to set
+ umask ovs-vswitchd daemon umask. This will allow ovsdb-server or
+ ovs-vswitchd to create sockets with access mode of 0770.
v3.1.0 - xx xxx
diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
index d91552588..0b2820c36 100644
--- a/utilities/ovs-ctl.in
+++ b/utilities/ovs-ctl.in
@@ -156,8 +156,8 @@ do_start_ovsdb () {
[ "$OVS_USER" != "" ] && set "$@" --user "$OVS_USER"
[ "$OVSDB_SERVER_OPTIONS" != "" ] && set "$@" $OVSDB_SERVER_OPTIONS
-start_daemon "$OVSDB_SERVER_PRIORITY" "$OVSDB_SERVER_WRAPPER" "$@" \
-|| return 1
+start_daemon "$OVSDB_SERVER_PRIORITY" "$OVSDB_SERVER_WRAPPER" \
+"$OVSDB_SERVER_UMASK" "$@" || return 1
# Initialize database settings.
ovs_vsctl -- init -- set Open_vSwitch . db-version="$schemaver" \
@@ -226,8 +226,8 @@ do_start_forwarding () {
[ "$OVS_USER" != "" ] && set "$@" --user "$OVS_USER"
[ "$OVS_VSWITCHD_OPTIONS" != "" ] &&set "$@" $OVS_VSWITCHD_OPTIONS
-start_daemon "$OVS_VSWITCHD_PRIORITY" "$OVS_VSWITCHD_WRAPPER" "$@" ||
-return 1
+start_daemon "$OVS_VSWITCHD_PRIORITY" "$OVS_VSWITCHD_WRAPPER" \
+"$OVS_VSWITCHD_UMASK" "$@" || return 1
fi
}
@@ -348,6 +348,8 @@ set_defaults () {
OVS_VSWITCHD_WRAPPER=
OVSDB_SERVER_OPTIONS=
OVS_VSWITCHD_OPTIONS=
+OVSDB_SERVER_UMASK=
+OVS_VSWITCHD_UMASK=
DB_FILE=$dbdir/conf.db
DB_SOCK=$rundir/db.sock
@@ -421,6 +423,12 @@ Other important options for "start", "restart" and
"force-reload-kmod":
add given key-value pair to Open_vSwitch external-ids
--delete-bridges delete all bridges just before starting ovs-vswitchd
--ovs-user="user[:group]" pass the --user flag to ovs daemons
+ --ovsdb-server-umask=MODE Set u
Re: [ovs-dev] [PATCH] utilities: add support to set umask in ovs-ctl
Hi Eelco, Ilya,
I’ve submitted v2 with requested changes addressed:
https://patchwork.ozlabs.org/project/openvswitch/patch/20230208152243.3686696-1-odiv...@gmail.com/Please,
let me know if this revision is okay or needs any improvements.
> On 7 Feb 2023, at 18:41, Eelco Chaudron wrote:
>
>
>
> On 7 Feb 2023, at 16:04, Vladislav Odintsov wrote:
>
>> Thanks for the review, Eelco!
>> Answers are inline.
>>
>>> On 7 Feb 2023, at 17:02, Eelco Chaudron wrote:
>>>
>>> See some comments inline below.
>>>
>>> Cheers,
>>>
>>> Eelco
>>>
>>> On 27 Jan 2023, at 14:29, Vladislav Odintsov wrote:
>>>
>>>> This patch adds a new ovs-ctl option to pass umask configuration to allow
>>>> OVS daemons to set requested socket permissions on group. Previous
>>>> behaviour (if using with systemd service unit) created sockets with 0750
>>>> permissions mask (group has no write permission).
>>>>
>>>> Write permission for group is reasonable in usecase, where ovs-vswitchd
>>>> or ovsdb-server runs as a non-privileged user:group (say,
>>>> openvswitch:openvswitch) and it is needed to access unix socket from
>>>> process running as another non-privileged user. In this case
>>>> administrator has to add that user to openvswitch group and can connect
>>>> to ovs sockets from that user.
>>>
>>> Will this affect any other files generated by vswitchd (logs?) that are now
>>> accessible by unprivileged users?
>>
>> I’ve checked other files: pidfile, logs, ovsdb lock files and see no
>> difference between default behaviour (no umask call) and when umask is set
>> to 0002, except for socket files:
>> pid files: 0644
>> log files: 0640
>> ovsdb lock: 0600
>> socket files have 0750 as a default value and 0770 if umask 000X is used (X
>> could be any value in the 0-7 range, if IIC).
>
> I did not find anything quickly that could be a loose end... Maybe someone
> else has some ideas.
>
>>>
>>>> Previous behaviour (not setting umask) is left as default.
>>>>
>>>> Reported-at:
>>>> https://mail.openvswitch.org/pipermail/ovs-dev/2023-January/401501.html
>>>> Signed-off-by: Vladislav Odintsov
>>>> ---
>>>> utilities/ovs-ctl.in | 8
>>>> 1 file changed, 8 insertions(+)
>>>>
>>>> diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
>>>> index e6e07f476..b97d568c6 100644
>>>> --- a/utilities/ovs-ctl.in
>>>> +++ b/utilities/ovs-ctl.in
>>>> @@ -334,6 +334,7 @@ set_defaults () {
>>>>SELF_CONFINEMENT=yes
>>>>MONITOR=yes
>>>>OVS_USER=
>>>> +OVS_UMASK=
>>>>OVSDB_SERVER=yes
>>>>OVS_VSWITCHD=yes
>>>>OVSDB_SERVER_PRIORITY=-10
>>>> @@ -415,6 +416,8 @@ Other important options for "start", "restart" and
>>>> "force-reload-kmod":
>>>> add given key-value pair to Open_vSwitch external-ids
>>>> --delete-bridges delete all bridges just before starting ovs-vswitchd
>>>> --ovs-user="user[:group]" pass the --user flag to ovs daemons
>>>> + --ovs-umask= Set umask prior to run OVS daemons.
>>>
>>> Rather than you might want to use MODE.
>>
>> Agree. Will address this in v2.
>>
>>>
>>>> +This is needed to manage socket group permissions.
>>>>
>>>> Less important options for "start", "restart" and "force-reload-kmod":
>>>> --daemon-cwd=DIR set working dir for OVS daemons (default:
>>>> $DAEMON_CWD)
>>>> @@ -542,6 +545,11 @@ do
>>>>;;
>>>>esac
>>>> done
>>>> +
>>>> +if [ -n "$OVS_UMASK" ]; then
>>>> +umask "$OVS_UMASK"
>>>> +fi
>>>
>>> The help mentions the list of commands are important
>>> start/restart/force-reload-kmod commands, but you set this umask for any
>>> command.
>>> Actually, the entire script is now executed with this umask, not only the
>>> daemons, if this is intended you might want to highlight it. Did not check
>>> if there is any implication for doing this.
>>
>> Hmm, nice point.
>> Maybe it would be better to move setting umask to ovs-lib.in file a
[ovs-dev] [PATCH v2] utilities: add support to set umask in ovs-ctl
This patch adds new ovs-ctl options to pass umask configuration to allow
OVS daemons set requested socket permissions on group. Previous
behaviour (if using with systemd service unit) created sockets with 0750
permissions mask (group has no write permission).
Write permission for group is reasonable in usecase, where ovs-vswitchd
or ovsdb-server runs as a non-privileged user:group (say,
openvswitch:openvswitch) and it is needed to access unix socket from
process running as another non-privileged user. In this case
administrator has to add that user to openvswitch group and can connect
to OVS sockets from a process running under that user.
Two new ovs-ctl options --ovsdb-server-umask and --ovs-vswitchd-umask
were added to manage umask values for appropriate daemons. This is
useful for systemd users: both ovs-vswitchd and ovsdb-server systemd
units read options from single /etc/sysconfig/openvswitch configuration
file. So, with separate options it is possible to set umask only for
specific daemon.
OPTIONS="--ovsdb-server-umask=0002"
in /etc/openvswitch/sysconfig file will set umask to 0002 value before
starting only ovsdb-server, while
OPTIONS="--ovs-vswitchd-umask=0002"
will set umask to ovs-vswitchd daemon.
Previous behaviour (not setting umask) is left as default.
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-dev/2023-January/401501.html
Signed-off-by: Vladislav Odintsov
---
v1 -> v2:
- added item in NEWS file as Ilya's suggestion;
- addressed Eelco's review comments;
- moved umask call from ovs-ctl to ovs-lib;
- added restoration of umask to effective value before the umask change;
- previous version --ovs-umask option was split into two:
--ovs-vswitchd-umask and --ovsdb-server-umask in order to make
possible umask configuration for specific daemon when running with
systemd.
Signed-off-by: Vladislav Odintsov
---
NEWS | 7 +++
utilities/ovs-ctl.in | 16
utilities/ovs-lib.in | 17 ++---
3 files changed, 33 insertions(+), 7 deletions(-)
diff --git a/NEWS b/NEWS
index fe6055a27..f7df598bd 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,13 @@ Post-v3.1.0
* OVS now collects per-interface upcall statistics that can be obtained
via 'ovs-appctl dpctl/show -s' or the interface's statistics column
in OVSDB. Available with upstream kernel 6.2+.
+ - ovs-ctl:
+ * Added support to set umask value when starting OVS daemons. New options
+ --ovsdb-server-umask=MODE and --ovs-vswitchd-umask=MODE were added for
+ that. For instance, when write access on befalf of OVS group is needed
+ for ovsdb-server, pass --ovsdb-umask=0002. Use --vswitchd-umask to set
+ umask ovs-vswitchd daemon umask. This will allow ovsdb-server or
+ ovs-vswitchd to create sockets with access mode of 0770.
v3.1.0 - xx xxx
diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
index d91552588..0b2820c36 100644
--- a/utilities/ovs-ctl.in
+++ b/utilities/ovs-ctl.in
@@ -156,8 +156,8 @@ do_start_ovsdb () {
[ "$OVS_USER" != "" ] && set "$@" --user "$OVS_USER"
[ "$OVSDB_SERVER_OPTIONS" != "" ] && set "$@" $OVSDB_SERVER_OPTIONS
-start_daemon "$OVSDB_SERVER_PRIORITY" "$OVSDB_SERVER_WRAPPER" "$@" \
-|| return 1
+start_daemon "$OVSDB_SERVER_PRIORITY" "$OVSDB_SERVER_WRAPPER" \
+"$OVSDB_SERVER_UMASK" "$@" || return 1
# Initialize database settings.
ovs_vsctl -- init -- set Open_vSwitch . db-version="$schemaver" \
@@ -226,8 +226,8 @@ do_start_forwarding () {
[ "$OVS_USER" != "" ] && set "$@" --user "$OVS_USER"
[ "$OVS_VSWITCHD_OPTIONS" != "" ] &&set "$@" $OVS_VSWITCHD_OPTIONS
-start_daemon "$OVS_VSWITCHD_PRIORITY" "$OVS_VSWITCHD_WRAPPER" "$@" ||
-return 1
+start_daemon "$OVS_VSWITCHD_PRIORITY" "$OVS_VSWITCHD_WRAPPER" \
+"$OVS_VSWITCHD_UMASK" "$@" || return 1
fi
}
@@ -348,6 +348,8 @@ set_defaults () {
OVS_VSWITCHD_WRAPPER=
OVSDB_SERVER_OPTIONS=
OVS_VSWITCHD_OPTIONS=
+OVSDB_SERVER_UMASK=
+OVS_VSWITCHD_UMASK=
DB_FILE=$dbdir/conf.db
DB_SOCK=$rundir/db.sock
@@ -421,6 +423,12 @@ Other important options for "start", "restart" and
"force-reload-kmod":
add given key-value pair to Open_vSwitch external-ids
--delete-bridges delete all bridges just before starting ovs-vswitchd
--ovs-user="user[:group]" pass the --user flag to ovs daemons
+ --ovsdb-server-umask=MODE Set umask prior to run ovs
Re: [ovs-dev] [PATCH] utilities: add support to set umask in ovs-ctl
Thanks for the review, Eelco!
Answers are inline.
> On 7 Feb 2023, at 17:02, Eelco Chaudron wrote:
>
> See some comments inline below.
>
> Cheers,
>
> Eelco
>
> On 27 Jan 2023, at 14:29, Vladislav Odintsov wrote:
>
>> This patch adds a new ovs-ctl option to pass umask configuration to allow
>> OVS daemons to set requested socket permissions on group. Previous
>> behaviour (if using with systemd service unit) created sockets with 0750
>> permissions mask (group has no write permission).
>>
>> Write permission for group is reasonable in usecase, where ovs-vswitchd
>> or ovsdb-server runs as a non-privileged user:group (say,
>> openvswitch:openvswitch) and it is needed to access unix socket from
>> process running as another non-privileged user. In this case
>> administrator has to add that user to openvswitch group and can connect
>> to ovs sockets from that user.
>
> Will this affect any other files generated by vswitchd (logs?) that are now
> accessible by unprivileged users?
I’ve checked other files: pidfile, logs, ovsdb lock files and see no difference
between default behaviour (no umask call) and when umask is set to 0002, except
for socket files:
pid files: 0644
log files: 0640
ovsdb lock: 0600
socket files have 0750 as a default value and 0770 if umask 000X is used (X
could be any value in the 0-7 range, if IIC).
>
>> Previous behaviour (not setting umask) is left as default.
>>
>> Reported-at:
>> https://mail.openvswitch.org/pipermail/ovs-dev/2023-January/401501.html
>> Signed-off-by: Vladislav Odintsov
>> ---
>> utilities/ovs-ctl.in | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
>> index e6e07f476..b97d568c6 100644
>> --- a/utilities/ovs-ctl.in
>> +++ b/utilities/ovs-ctl.in
>> @@ -334,6 +334,7 @@ set_defaults () {
>> SELF_CONFINEMENT=yes
>> MONITOR=yes
>> OVS_USER=
>> +OVS_UMASK=
>> OVSDB_SERVER=yes
>> OVS_VSWITCHD=yes
>> OVSDB_SERVER_PRIORITY=-10
>> @@ -415,6 +416,8 @@ Other important options for "start", "restart" and
>> "force-reload-kmod":
>> add given key-value pair to Open_vSwitch external-ids
>> --delete-bridges delete all bridges just before starting ovs-vswitchd
>> --ovs-user="user[:group]" pass the --user flag to ovs daemons
>> + --ovs-umask= Set umask prior to run OVS daemons.
>
> Rather than you might want to use MODE.
Agree. Will address this in v2.
>
>> +This is needed to manage socket group permissions.
>>
>> Less important options for "start", "restart" and "force-reload-kmod":
>> --daemon-cwd=DIR set working dir for OVS daemons (default:
>> $DAEMON_CWD)
>> @@ -542,6 +545,11 @@ do
>> ;;
>> esac
>> done
>> +
>> +if [ -n "$OVS_UMASK" ]; then
>> +umask "$OVS_UMASK"
>> +fi
>
> The help mentions the list of commands are important
> start/restart/force-reload-kmod commands, but you set this umask for any
> command.
> Actually, the entire script is now executed with this umask, not only the
> daemons, if this is intended you might want to highlight it. Did not check if
> there is any implication for doing this.
Hmm, nice point.
Maybe it would be better to move setting umask to ovs-lib.in file and pass
umask value to start_daemon() function?
It could be placed under setting nice value., right before running process with
"$@".
Also, we could split --ovs-umask option into two:
--ovsdb-umask, which sets umask only before ovsdb server start and
--vswitchd-umask, which sets umask only before ovs-vswitchd daemon start.
What do you think?
>
>> +
>> case $command in
>> start)
>> start_ovsdb || exit 1
>> --
>> 2.36.1
>>
>> ___
>> dev mailing list
>> d...@openvswitch.org <mailto:d...@openvswitch.org>
>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
> ___
> dev mailing list
> d...@openvswitch.org <mailto:d...@openvswitch.org>
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Regards,
Vladislav Odintsov
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] utilities: add support to set umask in ovs-ctl
Hi,
sure, no problem.
Should I do in a separate patch or incorporate into this one?
> On 7 Feb 2023, at 15:35, Ilya Maximets wrote:
>
> On 1/27/23 14:29, Vladislav Odintsov wrote:
>> This patch adds a new ovs-ctl option to pass umask configuration to allow
>> OVS daemons to set requested socket permissions on group. Previous
>> behaviour (if using with systemd service unit) created sockets with 0750
>> permissions mask (group has no write permission).
>>
>> Write permission for group is reasonable in usecase, where ovs-vswitchd
>> or ovsdb-server runs as a non-privileged user:group (say,
>> openvswitch:openvswitch) and it is needed to access unix socket from
>> process running as another non-privileged user. In this case
>> administrator has to add that user to openvswitch group and can connect
>> to ovs sockets from that user.
>>
>> Previous behaviour (not setting umask) is left as default.
>>
>> Reported-at:
>> https://mail.openvswitch.org/pipermail/ovs-dev/2023-January/401501.html
>> Signed-off-by: Vladislav Odintsov
>> ---
>> utilities/ovs-ctl.in | 8
>> 1 file changed, 8 insertions(+)
>
> Hi. Could you, please, also add a NEWS entry for this change?
> Thanks!
>
> Best regards, Ilya Maximets.
>
>>
>> diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
>> index e6e07f476..b97d568c6 100644
>> --- a/utilities/ovs-ctl.in
>> +++ b/utilities/ovs-ctl.in
>> @@ -334,6 +334,7 @@ set_defaults () {
>> SELF_CONFINEMENT=yes
>> MONITOR=yes
>> OVS_USER=
>> +OVS_UMASK=
>> OVSDB_SERVER=yes
>> OVS_VSWITCHD=yes
>> OVSDB_SERVER_PRIORITY=-10
>> @@ -415,6 +416,8 @@ Other important options for "start", "restart" and
>> "force-reload-kmod":
>> add given key-value pair to Open_vSwitch external-ids
>> --delete-bridges delete all bridges just before starting ovs-vswitchd
>> --ovs-user="user[:group]" pass the --user flag to ovs daemons
>> + --ovs-umask= Set umask prior to run OVS daemons.
>> +This is needed to manage socket group permissions.
>>
>> Less important options for "start", "restart" and "force-reload-kmod":
>> --daemon-cwd=DIR set working dir for OVS daemons (default:
>> $DAEMON_CWD)
>> @@ -542,6 +545,11 @@ do
>> ;;
>> esac
>> done
>> +
>> +if [ -n "$OVS_UMASK" ]; then
>> +umask "$OVS_UMASK"
>> +fi
>> +
>> case $command in
>> start)
>> start_ovsdb || exit 1
>
> ___
> dev mailing list
> d...@openvswitch.org <mailto:d...@openvswitch.org>
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Regards,
Vladislav Odintsov
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Wrong unix socket file permissions
I’ve sent a patch [0], please take a look on it when you have time. 0: https://patchwork.ozlabs.org/project/openvswitch/patch/20230127132950.3670502-1-odiv...@gmail.com/ > On 27 Jan 2023, at 13:14, Ilya Maximets wrote: > > On 1/27/23 10:25, Vladislav Odintsov wrote: >> What do you thing about setting umask in ovs-ctl script? >> I seems to be quite usable (it will work find with systemd and also with >> direct invocation of ovs-ctl script): >> >> diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in >> index e6e07f476..3c59469c4 100644 >> --- a/utilities/ovs-ctl.in >> +++ b/utilities/ovs-ctl.in >> @@ -544,6 +544,7 @@ do >> done >> case $command in >> start) >> +umask 0002 >> start_ovsdb || exit 1 >> start_forwarding || exit 1 >> add_managers > > Setting umask in the script is fine, but it has to be opt-in, otherwise > it might be a security concern. I guess, we could add another argument > to the script. Something like --ovs-umask=. Similar to existing > --ovs-user. > > Best regards, Ilya Maximets. > >> >>> On 26 Jan 2023, at 14:30, Ilya Maximets wrote: >>> >>> On 1/25/23 17:35, Vladislav Odintsov wrote: >>>> >>>> >>>> Regards, >>>> Vladislav Odintsov >>>> >>>>> On 25 Jan 2023, at 19:16, Ilya Maximets wrote: >>>>> >>>>> On 1/25/23 16:15, Vladislav Odintsov wrote: >>>>>> Hi, >>>>>> >>>>>> I’m a bit confused about linux unix socket files permissions, created by >>>>>> ovs daemons. >>>>>> >>>>>> From source code [0] I see it sets 0770 fchmod on file descriptor prior >>>>>> to socket bind(), assuming that sock file when creates will inherit FD’s >>>>>> permissions. So, I expect that after unix socket files created, they >>>>>> have rwxrwx--- permissions. >>>>>> >>>>>> However if running, for instance, ovsdb-server as root, it seems that >>>>>> this fchmod() call has no effect. Instead default root umask (0022) >>>>>> seems to be used: >>>>>> >>>>>> # ovsdb-server --remote punix:///var/run/openvswitch/ovs.sock >>>>>> /etc/openvswitch/ovs.db >>>>>> # ls -l /var/run/openvswitch/ovs.sock >>>>>> srwxr-x--- 1 root root 0 Jan 25 17:48 /var/run/openvswitch/ovs.sock >>>>> >>>>> The requested mode and umask are both effective. >>>>> The result is (mode & ~umask). In your case: >>>>> >>>>> 0770 & ~0022 = 0750, i.e. rwxr-x--- >>>>> >>>>>> >>>>>> If switch user to non-root (default umask 0002): >>>>>> >>>>>> $ ovsdb-server --remote punix://$(pwd)/ovs.sock >>>>>> --unixctl=$(pwd)/ctl.sock ./ovs.db >>>>>> $ ls -l ovs.sock >>>>>> srwxrwx--- 1 vlodintsov vlodintsov 0 Jan 25 17:42 ovs.sock >>>>> >>>>> 0770 & ~0002 = 0770 >>>>> >>>>>> >>>>>> If running as root, passing desired user as an argument to ovsdb-server, >>>>>> it still has the same as just root behaviour: >>>>>> >>>>>> # ovsdb-server --remote punix:///var/run/openvswitch/ovs.sock >>>>>> /etc/openvswitch/ovs.db --user openvswitch:openvswitch >>>>>> # ls -l /var/run/openvswitch/ovs.sock >>>>>> srwxr-x--- 1 openvswitch openvswitch 0 Jan 25 17:47 >>>>>> /var/run/openvswitch/ovs.sock >>>>>> >>>>>> >>>>>> This line of code [0] is quite old (about 8 years), so what am I doing >>>>>> wrong? >>>>>> Is it possible to make socket writable by group without extenal call >>>>>> chmod 0770 ? >>>>> Process has inherited umask from the current shell, i.e. the parent >>>>> process. umask is not a property of a user, it is typically set for >>>>> a shell session in bashrc or /etc/profile. >>>>> >>>>> OVS has no way to know what is the desired umask for the user we're >>>>> switching to. So, it remains the same as it was. >>>>> >>>>> Changing the umask for a current shell before starting the process >>>>> should help, e.g. >>&g
[ovs-dev] [PATCH] utilities: add support to set umask in ovs-ctl
This patch adds a new ovs-ctl option to pass umask configuration to allow
OVS daemons to set requested socket permissions on group. Previous
behaviour (if using with systemd service unit) created sockets with 0750
permissions mask (group has no write permission).
Write permission for group is reasonable in usecase, where ovs-vswitchd
or ovsdb-server runs as a non-privileged user:group (say,
openvswitch:openvswitch) and it is needed to access unix socket from
process running as another non-privileged user. In this case
administrator has to add that user to openvswitch group and can connect
to ovs sockets from that user.
Previous behaviour (not setting umask) is left as default.
Reported-at:
https://mail.openvswitch.org/pipermail/ovs-dev/2023-January/401501.html
Signed-off-by: Vladislav Odintsov
---
utilities/ovs-ctl.in | 8
1 file changed, 8 insertions(+)
diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
index e6e07f476..b97d568c6 100644
--- a/utilities/ovs-ctl.in
+++ b/utilities/ovs-ctl.in
@@ -334,6 +334,7 @@ set_defaults () {
SELF_CONFINEMENT=yes
MONITOR=yes
OVS_USER=
+OVS_UMASK=
OVSDB_SERVER=yes
OVS_VSWITCHD=yes
OVSDB_SERVER_PRIORITY=-10
@@ -415,6 +416,8 @@ Other important options for "start", "restart" and
"force-reload-kmod":
add given key-value pair to Open_vSwitch external-ids
--delete-bridges delete all bridges just before starting ovs-vswitchd
--ovs-user="user[:group]" pass the --user flag to ovs daemons
+ --ovs-umask= Set umask prior to run OVS daemons.
+This is needed to manage socket group permissions.
Less important options for "start", "restart" and "force-reload-kmod":
--daemon-cwd=DIR set working dir for OVS daemons (default:
$DAEMON_CWD)
@@ -542,6 +545,11 @@ do
;;
esac
done
+
+if [ -n "$OVS_UMASK" ]; then
+umask "$OVS_UMASK"
+fi
+
case $command in
start)
start_ovsdb || exit 1
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Wrong unix socket file permissions
What do you thing about setting umask in ovs-ctl script? I seems to be quite usable (it will work find with systemd and also with direct invocation of ovs-ctl script): diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in index e6e07f476..3c59469c4 100644 --- a/utilities/ovs-ctl.in +++ b/utilities/ovs-ctl.in @@ -544,6 +544,7 @@ do done case $command in start) +umask 0002 start_ovsdb || exit 1 start_forwarding || exit 1 add_managers > On 26 Jan 2023, at 14:30, Ilya Maximets wrote: > > On 1/25/23 17:35, Vladislav Odintsov wrote: >> >> >> Regards, >> Vladislav Odintsov >> >>> On 25 Jan 2023, at 19:16, Ilya Maximets wrote: >>> >>> On 1/25/23 16:15, Vladislav Odintsov wrote: >>>> Hi, >>>> >>>> I’m a bit confused about linux unix socket files permissions, created by >>>> ovs daemons. >>>> >>>> From source code [0] I see it sets 0770 fchmod on file descriptor prior to >>>> socket bind(), assuming that sock file when creates will inherit FD’s >>>> permissions. So, I expect that after unix socket files created, they have >>>> rwxrwx--- permissions. >>>> >>>> However if running, for instance, ovsdb-server as root, it seems that this >>>> fchmod() call has no effect. Instead default root umask (0022) seems to be >>>> used: >>>> >>>> # ovsdb-server --remote punix:///var/run/openvswitch/ovs.sock >>>> /etc/openvswitch/ovs.db >>>> # ls -l /var/run/openvswitch/ovs.sock >>>> srwxr-x--- 1 root root 0 Jan 25 17:48 /var/run/openvswitch/ovs.sock >>> >>> The requested mode and umask are both effective. >>> The result is (mode & ~umask). In your case: >>> >>> 0770 & ~0022 = 0750, i.e. rwxr-x--- >>> >>>> >>>> If switch user to non-root (default umask 0002): >>>> >>>> $ ovsdb-server --remote punix://$(pwd)/ovs.sock --unixctl=$(pwd)/ctl.sock >>>> ./ovs.db >>>> $ ls -l ovs.sock >>>> srwxrwx--- 1 vlodintsov vlodintsov 0 Jan 25 17:42 ovs.sock >>> >>> 0770 & ~0002 = 0770 >>> >>>> >>>> If running as root, passing desired user as an argument to ovsdb-server, >>>> it still has the same as just root behaviour: >>>> >>>> # ovsdb-server --remote punix:///var/run/openvswitch/ovs.sock >>>> /etc/openvswitch/ovs.db --user openvswitch:openvswitch >>>> # ls -l /var/run/openvswitch/ovs.sock >>>> srwxr-x--- 1 openvswitch openvswitch 0 Jan 25 17:47 >>>> /var/run/openvswitch/ovs.sock >>>> >>>> >>>> This line of code [0] is quite old (about 8 years), so what am I doing >>>> wrong? >>>> Is it possible to make socket writable by group without extenal call chmod >>>> 0770 ? >>> Process has inherited umask from the current shell, i.e. the parent >>> process. umask is not a property of a user, it is typically set for >>> a shell session in bashrc or /etc/profile. >>> >>> OVS has no way to know what is the desired umask for the user we're >>> switching to. So, it remains the same as it was. >>> >>> Changing the umask for a current shell before starting the process >>> should help, e.g. >>> >>> (umask 0002 && \ >>> ovsdb-server --remote punix:$(pwd)/ovs.sock /etc/openvswitch/ovs.db \ >>> --user openvswitch:openvswitch) >> >> So, if we use systemd service unit provided by ovs repo, we should edit >> .service file? >> Or maybe there is any other option for that? > > I don't think there is a way to change umask of a running process > from outside of that process. So something will need to be modified. > It can be a service file (UMask=...), or an ovs-ctl script or the > code of the daemons themselves. > >> >>> >>> Best regards, Ilya Maximets. >>> >>>> >>>> 0: >>>> https://github.com/openvswitch/ovs/blob/v2.17.5/lib/socket-util-unix.c#L264 >>>> >>>> Regards, >>>> Vladislav Odintsov >>> >> > > ___ > dev mailing list > d...@openvswitch.org <mailto:d...@openvswitch.org> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] Wrong unix socket file permissions
Regards, Vladislav Odintsov > On 25 Jan 2023, at 19:16, Ilya Maximets wrote: > > On 1/25/23 16:15, Vladislav Odintsov wrote: >> Hi, >> >> I’m a bit confused about linux unix socket files permissions, created by ovs >> daemons. >> >> From source code [0] I see it sets 0770 fchmod on file descriptor prior to >> socket bind(), assuming that sock file when creates will inherit FD’s >> permissions. So, I expect that after unix socket files created, they have >> rwxrwx--- permissions. >> >> However if running, for instance, ovsdb-server as root, it seems that this >> fchmod() call has no effect. Instead default root umask (0022) seems to be >> used: >> >> # ovsdb-server --remote punix:///var/run/openvswitch/ovs.sock >> /etc/openvswitch/ovs.db >> # ls -l /var/run/openvswitch/ovs.sock >> srwxr-x--- 1 root root 0 Jan 25 17:48 /var/run/openvswitch/ovs.sock > > The requested mode and umask are both effective. > The result is (mode & ~umask). In your case: > > 0770 & ~0022 = 0750, i.e. rwxr-x--- > >> >> If switch user to non-root (default umask 0002): >> >> $ ovsdb-server --remote punix://$(pwd)/ovs.sock --unixctl=$(pwd)/ctl.sock >> ./ovs.db >> $ ls -l ovs.sock >> srwxrwx--- 1 vlodintsov vlodintsov 0 Jan 25 17:42 ovs.sock > > 0770 & ~0002 = 0770 > >> >> If running as root, passing desired user as an argument to ovsdb-server, it >> still has the same as just root behaviour: >> >> # ovsdb-server --remote punix:///var/run/openvswitch/ovs.sock >> /etc/openvswitch/ovs.db --user openvswitch:openvswitch >> # ls -l /var/run/openvswitch/ovs.sock >> srwxr-x--- 1 openvswitch openvswitch 0 Jan 25 17:47 >> /var/run/openvswitch/ovs.sock >> >> >> This line of code [0] is quite old (about 8 years), so what am I doing wrong? >> Is it possible to make socket writable by group without extenal call chmod >> 0770 ? > Process has inherited umask from the current shell, i.e. the parent > process. umask is not a property of a user, it is typically set for > a shell session in bashrc or /etc/profile. > > OVS has no way to know what is the desired umask for the user we're > switching to. So, it remains the same as it was. > > Changing the umask for a current shell before starting the process > should help, e.g. > > (umask 0002 && \ > ovsdb-server --remote punix:$(pwd)/ovs.sock /etc/openvswitch/ovs.db \ > --user openvswitch:openvswitch) So, if we use systemd service unit provided by ovs repo, we should edit .service file? Or maybe there is any other option for that? > > Best regards, Ilya Maximets. > >> >> 0: >> https://github.com/openvswitch/ovs/blob/v2.17.5/lib/socket-util-unix.c#L264 >> >> Regards, >> Vladislav Odintsov > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Wrong unix socket file permissions
Hi, I’m a bit confused about linux unix socket files permissions, created by ovs daemons. From source code [0] I see it sets 0770 fchmod on file descriptor prior to socket bind(), assuming that sock file when creates will inherit FD’s permissions. So, I expect that after unix socket files created, they have rwxrwx--- permissions. However if running, for instance, ovsdb-server as root, it seems that this fchmod() call has no effect. Instead default root umask (0022) seems to be used: # ovsdb-server --remote punix:///var/run/openvswitch/ovs.sock /etc/openvswitch/ovs.db # ls -l /var/run/openvswitch/ovs.sock srwxr-x--- 1 root root 0 Jan 25 17:48 /var/run/openvswitch/ovs.sock If switch user to non-root (default umask 0002): $ ovsdb-server --remote punix://$(pwd)/ovs.sock --unixctl=$(pwd)/ctl.sock ./ovs.db $ ls -l ovs.sock srwxrwx--- 1 vlodintsov vlodintsov 0 Jan 25 17:42 ovs.sock If running as root, passing desired user as an argument to ovsdb-server, it still has the same as just root behaviour: # ovsdb-server --remote punix:///var/run/openvswitch/ovs.sock /etc/openvswitch/ovs.db --user openvswitch:openvswitch # ls -l /var/run/openvswitch/ovs.sock srwxr-x--- 1 openvswitch openvswitch 0 Jan 25 17:47 /var/run/openvswitch/ovs.sock This line of code [0] is quite old (about 8 years), so what am I doing wrong? Is it possible to make socket writable by group without extenal call chmod 0770 ? 0: https://github.com/openvswitch/ovs/blob/v2.17.5/lib/socket-util-unix.c#L264 Regards, Vladislav Odintsov ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [OVN RFC 0/7] OVN IC bugfixes & proposals/questions
Thanks Ilya for the quick and useful response!
We’ll dig into monitor/db_change_aware logic.
Regards,
Vladislav Odintsov
> On 24 Jan 2023, at 17:00, Ilya Maximets wrote:
>
> On 1/24/23 14:12, Vladislav Odintsov wrote:
>> Hi Ilya,
>>
>> could you please take a look on this?
>> Maybe you can advice any direction how to investigate this issue?
>>
>> Thanks in advance.
>>
>> Regards,
>> Vladislav Odintsov
>>
>>> On 24 Nov 2022, at 21:10, Anton Vazhnetsov wrote:
>>>
>>> Hi, Terry!
>>>
>>> In continuation to our yesterday’s conversation [0], we were able to
>>> reproduce the issue with KeyError. We found that the problem is not
>>> connected with ovsdb-server load but it appears when the ovsdb-server
>>> schema is converted online (it even doesn’t matter whether the real ovs
>>> schema is changed) while the active connection persists.
>>> Please use next commands to reproduce it:
>>>
>>> # in terminal 1
>>>
>>> ovsdb-tool create ./ovs.db /usr/share/ovn/ovn-nb.ovsschema
>>> ovsdb-server --remote punix://$(pwd)/ovs.sock
>>> $(pwd)/ovs.db -vconsole:dbg
>>>
>>>
>>> # in terminal 2. run python shell
>>> python3
>>> # setup connection
>>> import ovsdbapp.schema.ovn_northbound.impl_idl as nb_idl
>>> from ovsdbapp.backend.ovs_idl import connection
>>>
>>> remote = "unix:///"
>>>
>>> def get_idl():
>>>"""Connection getter."""
>>>
>>>idl = connection.OvsdbIdl.from_server(remote, "OVN_Northbound",
>>> leader_only=False)
>>>return nb_idl.OvnNbApiIdlImpl(connection.Connection(idl, 100))
>>>
>>> idl = get_idl()
>>>
>>>
>>> # in terminal 1
>>> ovsdb-client convert unix:$(pwd)/ovs.sock /usr/share/ovn/ovn-nb.ovsschema
>>>
>>> # in terminal 2 python shell:
>>> idl.ls_add("test").execute()
>>>
>>>
>>> We get following traceback:
>>>
>>> Traceback (most recent call last):
>>> File
>>> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/connection.py",
>>> line 131, in run
>>>txn.results.put(txn.do_commit())
>>> File
>>> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/transaction.py",
>>> line 143, in do_commit
>>>self.post_commit(txn)
>>> File
>>> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/transaction.py",
>>> line 73, in post_commit
>>>command.post_commit(txn)
>>> File
>>> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/command.py",
>>> line 94, in post_commit
>>>row = self.api.tables[self.table_name].rows[real_uuid]
>>> File "/usr/lib64/python3.6/collections/__init__.py", line 991, in
>>> __getitem__
>>>raise KeyError(key)
>>> KeyError: UUID('0256afa4-6dd0-4c2c-b6a2-686a360ab331')
>>>
>>> In ovsdb-server debug logs we see that update2 or update3 messages are not
>>> sent from server in response to client’s transaction, just reply with
>>> result UUID:
>>> 2022-11-24T17:42:36Z|00306|poll_loop|DBG|wakeup due to [POLLIN] on fd 18
>>> (///root/ovsdb-problem/ovs.sock<->) at lib/stream-fd.c:157
>>> 2022-11-24T17:42:36Z|00307|jsonrpc|DBG|unix#5: received request,
>>> method="transact",
>>> params=["OVN_Northbound",{"uuid-name":"row03ef28d6_93f1_43bc_b07a_eae58d4bd1c5","table":"Logical_Switch","op":"insert","row":{"name”:"test"}}],
>>> id=5
>>> 2022-11-24T17:42:36Z|00308|jsonrpc|DBG|unix#5: send reply,
>>> result=[{"uuid":["uuid","4eb7c407-beec-46ca-b816-19f942e57721"]}], id=5
>>>
>>> We checked same with ovn-nbctl running in daemon mode and found that the
>>> problem is not reproduced (ovsdb-server after database conversion sends out
>>> update3 message to ovn-nbctl daemon process in response to transaction, for
>>> example ovs-appctl -t run ls-add test-ls):
>
> If the update3 is not sent, it means that the client doesn't monitor
> this table. You need to look at monitor requests sent and replied
> to figure out the difference.
>
> Since the database conversion is involved, s
Re: [ovs-dev] [OVN RFC 0/7] OVN IC bugfixes & proposals/questions
Hi Ilya,
could you please take a look on this?
Maybe you can advice any direction how to investigate this issue?
Thanks in advance.
Regards,
Vladislav Odintsov
> On 24 Nov 2022, at 21:10, Anton Vazhnetsov wrote:
>
> Hi, Terry!
>
> In continuation to our yesterday’s conversation [0], we were able to
> reproduce the issue with KeyError. We found that the problem is not connected
> with ovsdb-server load but it appears when the ovsdb-server schema is
> converted online (it even doesn’t matter whether the real ovs schema is
> changed) while the active connection persists.
> Please use next commands to reproduce it:
>
> # in terminal 1
>
> ovsdb-tool create ./ovs.db /usr/share/ovn/ovn-nb.ovsschema
> ovsdb-server --remote punix://$(pwd)/ovs.sock $(pwd)/ovs.db -vconsole:dbg
>
>
> # in terminal 2. run python shell
> python3
> # setup connection
> import ovsdbapp.schema.ovn_northbound.impl_idl as nb_idl
> from ovsdbapp.backend.ovs_idl import connection
>
> remote = "unix:///"
>
> def get_idl():
>"""Connection getter."""
>
>idl = connection.OvsdbIdl.from_server(remote, "OVN_Northbound",
> leader_only=False)
>return nb_idl.OvnNbApiIdlImpl(connection.Connection(idl, 100))
>
> idl = get_idl()
>
>
> # in terminal 1
> ovsdb-client convert unix:$(pwd)/ovs.sock /usr/share/ovn/ovn-nb.ovsschema
>
> # in terminal 2 python shell:
> idl.ls_add("test").execute()
>
>
> We get following traceback:
>
> Traceback (most recent call last):
> File
> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/connection.py",
> line 131, in run
>txn.results.put(txn.do_commit())
> File
> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/transaction.py",
> line 143, in do_commit
>self.post_commit(txn)
> File
> "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/transaction.py",
> line 73, in post_commit
>command.post_commit(txn)
> File "/usr/lib/python3.6/site-packages/ovsdbapp/backend/ovs_idl/command.py",
> line 94, in post_commit
>row = self.api.tables[self.table_name].rows[real_uuid]
> File "/usr/lib64/python3.6/collections/__init__.py", line 991, in __getitem__
>raise KeyError(key)
> KeyError: UUID('0256afa4-6dd0-4c2c-b6a2-686a360ab331')
>
> In ovsdb-server debug logs we see that update2 or update3 messages are not
> sent from server in response to client’s transaction, just reply with result
> UUID:
> 2022-11-24T17:42:36Z|00306|poll_loop|DBG|wakeup due to [POLLIN] on fd 18
> (///root/ovsdb-problem/ovs.sock<->) at lib/stream-fd.c:157
> 2022-11-24T17:42:36Z|00307|jsonrpc|DBG|unix#5: received request,
> method="transact",
> params=["OVN_Northbound",{"uuid-name":"row03ef28d6_93f1_43bc_b07a_eae58d4bd1c5","table":"Logical_Switch","op":"insert","row":{"name”:"test"}}],
> id=5
> 2022-11-24T17:42:36Z|00308|jsonrpc|DBG|unix#5: send reply,
> result=[{"uuid":["uuid","4eb7c407-beec-46ca-b816-19f942e57721"]}], id=5
>
> We checked same with ovn-nbctl running in daemon mode and found that the
> problem is not reproduced (ovsdb-server after database conversion sends out
> update3 message to ovn-nbctl daemon process in response to transaction, for
> example ovs-appctl -t run ls-add test-ls):
> 2022-11-24T17:54:51Z|00623|jsonrpc|DBG|unix#7: received request,
> method="transact",
> params=["OVN_Northbound",{"uuid-name":"rowcdb152ce_a9af_4761_b965_708ad300fcb7","table":"Logical_Switch","op":"insert","row":{"name":"test-ls"}},{"comment":"ovn-nbctl:
> run ls-add test-ls","op":"comment"}], id=5
> 2022-11-24T17:54:51Z|00624|jsonrpc|DBG|unix#7: send notification,
> method="update3",
> params=[["monid","OVN_Northbound"],"----",{"Logical_Switch":{"0b147f2c-248d-496a-b718-a5328d3c2995":{"insert":{"name":"test-ls"]
> 2022-11-24T17:54:51Z|00625|jsonrpc|DBG|unix#7: send reply,
> result=[{"uuid":["uuid","0b147f2c-248d-496a-b718-a5328d3c2995"]},{}], id=5
>
> So it seems that the problem is in python-ovs, not in ovsdb-server.
> We tested with ovsdb-server running version 2.17.3 and python-ovs 2.13.5 and
> also python-ovs 2.17.3, the behaviour is the same.
>
> Do you have any ideas what can be a reason for such behaviour?
>
> 0:
> https://review.opendev.org/c/openstack/ovsdbapp/+/865454/comments/674c57e6_3849591b
>
> Regards, Anton.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v2 1/2] northd: make traffic routed to vtep lport distributed
Thanks Dumitru! Regards, Vladislav Odintsov > On 23 Jan 2023, at 17:58, Dumitru Ceara wrote: > > On 1/23/23 10:15, Simon Horman wrote: >> On Sat, Jan 21, 2023 at 07:46:07PM +0300, Vladislav Odintsov wrote: >>> There were two issues prior to this patch: >>> 1. It was unable to have connectivity to networks over a router in >>> physical network connected through VTEP (ramp) gateway. >>> Consider next topology: >>> >>> ovn-nbctl lr-add lr1 >>> ovn-nbctl lrp-add lr1 lrp1 00:00:00:00:00:01 10.0.0.1/24 >>> ovn-nbctl ls-add ls1 >>> ovn-nbctl lrp-add ls1 lsp1 -- \ >>> lsp-set-addresses lsp1 router -- \ >>> lsp-set-type lsp1 router -- \ >>> lsp-set-options lsp1 router-port=lrp1 >>> ovn-nbctl lsp-add ls1 lsp-vtep -- \ >>> lsp-set-type lsp-vtep vtep -- \ >>> lsp-set-addresses lsp-vtep unknown -- \ >>> lsp-set-options lsp-vtep vtep-physical-switch=<..> >>> vtep-logical-switch=<..> >>> ovn-nbctl lr-route-add lr1 192.168.0.0/24 10.0.0.100 >>> >>> If one issues ping from lsp1 to some address from 192.168.0.0/24 (via >>> vtep lsp), to enable routing support with vtep it is required to set >>> redirect chassis or ha chassis group on lrp1. This topology didn't >>> provide connectivity. Now such traffic flow will work properly. >>> >>> 2. Traffic from lport in one subnet to vtep lport in another subnet of >>> same LR previously traversed via l3gw chassis, now in 'to vtep lport' >>> direction goes directly from hypervisor handling lport to VTEP (RAMP) >>> switch. In the opposite direction traffic still goes from VTEP (RAMP) >>> switch through l3gw chassis and then to hypervisor. >>> >>> The described functionality changes achieved by skipping to add >>> gateway redirect logical flow for l3dgw ports which peers have datapath >>> with logical switch ports of 'vtep' type. >>> In this case traffic from hypervisor to VTEP (ramp) switch should go in >>> distributed manner. Only returning routed traffic must go through >>> centralized gateway or ha-chassis-group. >>> >>> This patch also updates relevant testcases to check the changed flows >>> generation and port_binding:options:always-redirect logic. >>> >>> Signed-off-by: Vladislav Odintsov >> >> Thanks for the updates since v1, they look good to me. >> >> FWIIW, >> >> Reviewed-by: Simon Horman >> ___ > > Thanks, Vladislav and Simon! I applied these two patches to the main > branch. > > Regards, > Dumitru > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v3 0/4] Add support for OVSDB Relay in OVN SB DB
Thanks Dumitru!
Regards,
Vladislav Odintsov
> On 23 Jan 2023, at 17:59, Dumitru Ceara wrote:
>
> On 1/21/23 15:54, Vladislav Odintsov wrote:
>> v2->v3:
>> - Address Dumitru's comment regarding wrong %systemd_postun rpm macro
>> usage.
>> - Rebase on current main branch.
>>
>> v1->v2:
>> - Added post/preun/postun scripts to manage systemd-related logic around
>> new service unit.
>>
>> This patch series adds support to run utilize OVSDB Relay functionality
>> in OVN:
>> - add new commands to ovn-ctl script
>> - add new systemd-unit ovn-db@.service to manage ovsdb-servers
>> - add support to run against non-leader to ovn-controller-vtep
>> - add documentation about OVSDB Relay usage in OVN
>>
>> Vladislav Odintsov (4):
>> rhel,ovn-ctl: add support to run OVN SB relay
>> rhel: add ovn-db@.service systemd-unit
>> vtep: set SB DB ovsdb_idl to no_leader_only mode
>> docs: add tutorial for ovsdb relay usage
>
> Thanks, Vladislav for the patches and Ales for the reviews!
>
> I fixed a typo in the last patch ("horisontally") and pushed these to
> the main branch.
>
> Regards,
> Dumitru
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn 1/2] northd: make traffic routed to vtep lport distributed
Please check out the v2:
https://patchwork.ozlabs.org/project/ovn/patch/20230121164609.3625347-1-odiv...@gmail.com/
Regards,
Vladislav Odintsov
> On 21 Jan 2023, at 15:47, Vladislav Odintsov wrote:
>
> Hi Simon,
>
> thanks for the review.
> I agree with all your comments and I’ll address them in v2.
>
> Regards,
> Vladislav Odintsov
>
>> On 18 Jan 2023, at 16:08, Simon Horman wrote:
>>
>> On Thu, Dec 22, 2022 at 08:43:08PM +0300, Vladislav Odintsov wrote:
>>> There were two issues prior to this patch:
>>> 1. It was unable to have connectivity to networks over a router in
>>> physical network connected through VTEP (ramp) gateway.
>>> Consider next topology:
>>>
>>> ovn-nbctl lr-add lr1
>>> ovn-nbctl lrp-add lr1 lrp1 00:00:00:00:00:01 10.0.0.1/24
>>> ovn-nbctl ls-add ls1
>>> ovn-nbctl lrp-add ls1 lsp1 -- \
>>> lsp-set-addresses lsp1 router -- \
>>> lsp-set-type lsp1 router -- \
>>> lsp-set-options lsp1 router-port=lrp1
>>> ovn-nbctl lsp-add ls1 lsp-vtep -- \
>>> lsp-set-type lsp-vtep vtep -- \
>>> lsp-set-addresses lsp-vtep unknown -- \
>>> lsp-set-options lsp-vtep vtep-physical-switch=<..>
>>> vtep-logical-switch=<..>
>>> ovn-nbctl lr-route-add lr1 192.168.0.0/24 10.0.0.100
>>>
>>> If one issues ping from lsp1 to some address from 192.168.0.0/24 (via
>>> vtep lsp), to enable routing support with vtep it is required to set
>>> redirect chassis or ha chassis group on lrp1. This topology didn't
>>> provide connectivity. Now such traffic flow will work properly.
>>>
>>> 2. Traffic from lport in one subnet to vtep lport in another subnet of
>>> same LR previously traversed via l3gw chassis, now in 'to vtep lport'
>>> direction goes directly from hypervisor handling lport to VTEP (RAMP)
>>> switch. In the opposite direction traffic still goes from VTEP (RAMP)
>>> switch through l3gw chassis and then to hypervisor.
>>
>> I think it would be good to explain how the logic changes
>> addresses these problems. And breifly describe which tests have been added.
>>
>>>
>>> Signed-off-by: Vladislav Odintsov
>>> ---
>>> northd/northd.c | 16 +++-
>>> tests/ovn-northd.at | 26 +-
>>> 2 files changed, 40 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/northd/northd.c b/northd/northd.c
>>> index 4751feab4..07fb0ab9a 100644
>>> --- a/northd/northd.c
>>> +++ b/northd/northd.c
>>> @@ -3362,7 +3362,12 @@ ovn_port_update_sbrec(struct northd_input
>>> *input_data,
>>> }
>>> smap_add(&new, "distributed-port", op->nbrp->name);
>>>
>>> -bool always_redirect = !op->od->has_distributed_nat;
>>> +bool always_redirect = !(
>>> +op->od->has_distributed_nat ||
>>> +(op->l3dgw_port->peer &&
>>> + op->l3dgw_port->peer->od->has_vtep_lports)
>>> +);
>>
>> This seems slightly easier on my brain:
>>
>>bool always_redirect =
>>!op->od->has_distributed_nat &&
>>!(op->l3dgw_port->peer &&
>> op->l3dgw_port->peer->od->has_vtep_lports)
>>
>>> +
>>> if (redirect_type) {
>>> smap_add(&new, "redirect-type", redirect_type);
>>> /* XXX Why can't we enable always-redirect when
>>> redirect-type
>>> @@ -12815,6 +12820,15 @@ build_gateway_redirect_flows_for_lrouter(
>>> return;
>>> }
>>> for (size_t i = 0; i < od->n_l3dgw_ports; i++) {
>>> +if (od->l3dgw_ports[i]->peer &&
>>> +od->l3dgw_ports[i]->peer->od->has_vtep_lports) {
>>
>> This condition appears twice in this patch.
>> Perhaps a helper would make its meaning more obvious.
>>
>>> +/* Skip adding redirect rule for vtep-enabled l3dgw ports.
>>> + Traffic from hypervisor to VTEP (ramp) switch should go in
>>> + distributed manner. Only returning routed traffic must go
>>> + through centralized gateway (or ha-chassis-group). */
>>
>> nit:
>> /* Multi-line comments
>> * look like this. */
>>
>>> +continue;
>>> +}
>>> +
>>> const struct ovsdb_idl_row *stage_hint = NULL;
>>> bool add_def_flow = true;
>>>
>>
>> ...
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn v2 2/2] northd: fix typo in consider_l3d{wg, gw}... function
This patch fixes typo in consider_l3dgw_port_is_centralized() function.
Signed-off-by: Vladislav Odintsov
Reviewed-by: Simon Horman
---
northd/northd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index 46ed39850..bc2d79164 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -11636,7 +11636,7 @@ build_gateway_mtu_flow(struct hmap *lflows, struct
ovn_port *op,
}
static bool
-consider_l3dwg_port_is_centralized(struct ovn_port *op)
+consider_l3dgw_port_is_centralized(struct ovn_port *op)
{
if (l3dgw_port_has_associated_vtep_lports(op)) {
return false;
@@ -11687,7 +11687,7 @@ build_adm_ctrl_flows_for_lrouter_port(
ds_clear(match);
ds_put_format(match, "eth.dst == %s && inport == %s",
op->lrp_networks.ea_s, op->json_key);
-if (consider_l3dwg_port_is_centralized(op)) {
+if (consider_l3dgw_port_is_centralized(op)) {
ds_put_format(match, " && is_chassis_resident(%s)",
op->cr_port->json_key);
}
--
2.36.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn v2 1/2] northd: make traffic routed to vtep lport distributed
There were two issues prior to this patch:
1. It was unable to have connectivity to networks over a router in
physical network connected through VTEP (ramp) gateway.
Consider next topology:
ovn-nbctl lr-add lr1
ovn-nbctl lrp-add lr1 lrp1 00:00:00:00:00:01 10.0.0.1/24
ovn-nbctl ls-add ls1
ovn-nbctl lrp-add ls1 lsp1 -- \
lsp-set-addresses lsp1 router -- \
lsp-set-type lsp1 router -- \
lsp-set-options lsp1 router-port=lrp1
ovn-nbctl lsp-add ls1 lsp-vtep -- \
lsp-set-type lsp-vtep vtep -- \
lsp-set-addresses lsp-vtep unknown -- \
lsp-set-options lsp-vtep vtep-physical-switch=<..>
vtep-logical-switch=<..>
ovn-nbctl lr-route-add lr1 192.168.0.0/24 10.0.0.100
If one issues ping from lsp1 to some address from 192.168.0.0/24 (via
vtep lsp), to enable routing support with vtep it is required to set
redirect chassis or ha chassis group on lrp1. This topology didn't
provide connectivity. Now such traffic flow will work properly.
2. Traffic from lport in one subnet to vtep lport in another subnet of
same LR previously traversed via l3gw chassis, now in 'to vtep lport'
direction goes directly from hypervisor handling lport to VTEP (RAMP)
switch. In the opposite direction traffic still goes from VTEP (RAMP)
switch through l3gw chassis and then to hypervisor.
The described functionality changes achieved by skipping to add
gateway redirect logical flow for l3dgw ports which peers have datapath
with logical switch ports of 'vtep' type.
In this case traffic from hypervisor to VTEP (ramp) switch should go in
distributed manner. Only returning routed traffic must go through
centralized gateway or ha-chassis-group.
This patch also updates relevant testcases to check the changed flows
generation and port_binding:options:always-redirect logic.
Signed-off-by: Vladislav Odintsov
---
northd/northd.c | 26 --
tests/ovn-northd.at | 26 +-
2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/northd/northd.c b/northd/northd.c
index 40a302579..46ed39850 100644
--- a/northd/northd.c
+++ b/northd/northd.c
@@ -3302,6 +3302,14 @@ sbrec_port_binding_update_mirror_rules(struct
northd_input *input_data,
check_and_do_sb_mirror_addition(input_data, op);
}
+/* Return true if given ovn_port has peer and this peer's ovn_datapath
+ * has_vtep_lports set to true. False otherwise. */
+static bool
+l3dgw_port_has_associated_vtep_lports(const struct ovn_port *op)
+{
+return op->peer && op->peer->od->has_vtep_lports;
+}
+
static void
ovn_port_update_sbrec(struct northd_input *input_data,
struct ovsdb_idl_txn *ovnsb_txn,
@@ -3371,7 +3379,10 @@ ovn_port_update_sbrec(struct northd_input *input_data,
}
smap_add(&new, "distributed-port", op->nbrp->name);
-bool always_redirect = !op->od->has_distributed_nat;
+bool always_redirect =
+!op->od->has_distributed_nat &&
+!l3dgw_port_has_associated_vtep_lports(op->l3dgw_port);
+
if (redirect_type) {
smap_add(&new, "redirect-type", redirect_type);
/* XXX Why can't we enable always-redirect when redirect-type
@@ -11627,7 +11638,7 @@ build_gateway_mtu_flow(struct hmap *lflows, struct
ovn_port *op,
static bool
consider_l3dwg_port_is_centralized(struct ovn_port *op)
{
-if (op->peer && op->peer->od->has_vtep_lports) {
+if (l3dgw_port_has_associated_vtep_lports(op)) {
return false;
}
@@ -12833,6 +12844,17 @@ build_gateway_redirect_flows_for_lrouter(
return;
}
for (size_t i = 0; i < od->n_l3dgw_ports; i++) {
+if (l3dgw_port_has_associated_vtep_lports(od->l3dgw_ports[i])) {
+/* Skip adding redirect lflow for vtep-enabled l3dgw ports.
+ * Traffic from hypervisor to VTEP (ramp) switch should go in
+ * distributed manner. Only returning routed traffic must go
+ * through centralized gateway (or ha-chassis-group).
+ * This assumes that attached logical switch with vtep lport(s) has
+ * no localnet port(s) for NAT. Otherwise centralized NAT will not
+ * work. */
+continue;
+}
+
const struct ovsdb_idl_row *stage_hint = NULL;
bool add_def_flow = true;
diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
index 35f186ad6..941460d5b 100644
--- a/tests/ovn-northd.at
+++ b/tests/ovn-northd.at
@@ -6075,7 +6075,7 @@ AT_CLEANUP
])
OVN_FOR_EACH_NORTHD_NO_HV([
-AT_SETUP([ovn-northd -- lr admission with vtep lports])
+AT_SETUP([ovn-northd -- lrp with chassis-redirect and ls with vtep lport])
AT_KEYWORDS([multiple-l3dgw-p
[ovs-dev] [PATCH ovn v3 3/4] vtep: set SB DB ovsdb_idl to no_leader_only mode
This adds capability to run ovn-controller-vtep against OVN Southbound OVSDB server running in relay mode. Signed-off-by: Vladislav Odintsov Reviewed-by: Ales Musil --- controller-vtep/ovn-controller-vtep.c | 1 + 1 file changed, 1 insertion(+) diff --git a/controller-vtep/ovn-controller-vtep.c b/controller-vtep/ovn-controller-vtep.c index 3f177d193..26f8fd115 100644 --- a/controller-vtep/ovn-controller-vtep.c +++ b/controller-vtep/ovn-controller-vtep.c @@ -154,6 +154,7 @@ main(int argc, char *argv[]) ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_port_binding_col_type); ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_port_binding_col_up); +ovsdb_idl_set_leader_only(ovnsb_idl_loop.idl, false); ovsdb_idl_get_initial_snapshot(ovnsb_idl_loop.idl); char *ovn_version = ovn_get_internal_version(); -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn v3 1/4] rhel, ovn-ctl: add support to run OVN SB relay
New ovn-ctl commands were added:
- start_sb_relay_ovsdb
- stop_sb_relay_ovsdb
- restart_sb_relay_ovsdb
Required configuration parameters are:
--db-sb-relay-remote - needed to supply upstream cluster/server remote.
Optionally user may pass next parameters:
--db-sb-relay-sock
--db-sb-relay-pidfile
--db-sb-relay-ctrl-sock
--db-sb-relay-use-remote-in-db
--ovn-sb-relay-db-ssl-key
--ovn-sb-relay-db-ssl-cert
--ovn-sb-relay-db-ssl-ca-cert
Signed-off-by: Vladislav Odintsov
Reviewed-by: Ales Musil
---
NEWS | 1 +
utilities/ovn-ctl | 56 ++-
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index 2e0d54ae6..9aeeac10b 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,7 @@ Post v22.12.0
-
- ovn-controller: Experimental support for co-hosting multiple controller
instances on the same host.
+ - Add ovn-ctl commands for (re)starting/stopping OVSDB relay for OVN SB DB.
OVN v22.12.0 - 16 Dec 2022
--
diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index 93be9b84b..dc8865abf 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -84,6 +84,10 @@ stop_ic_ovsdb () {
stop_ic_sb_ovsdb
}
+stop_sb_relay_ovsdb() {
+OVS_RUNDIR=${OVS_RUNDIR} stop_ovn_daemon ovnsb_relay $DB_SB_RELAY_PIDFILE
$DB_SB_RELAY_CTRL_SOCK
+}
+
demote_xx_ovsdb () {
local sync_from_addr=$1
local sync_from_proto=$2
@@ -179,6 +183,7 @@ start_ovsdb__() {
local ovn_db_ssl_cert
local ovn_db_ssl_cacert
local ovn_db_election_timer
+local relay_mode
eval db_pid_file=\$DB_${DB}_PIDFILE
eval cluster_local_addr=\$DB_${DB}_CLUSTER_LOCAL_ADDR
eval cluster_local_port=\$DB_${DB}_CLUSTER_LOCAL_PORT
@@ -205,6 +210,8 @@ start_ovsdb__() {
eval ovn_db_ssl_cert=\$OVN_${DB}_DB_SSL_CERT
eval ovn_db_ssl_cacert=\$OVN_${DB}_DB_SSL_CA_CERT
eval ovn_db_election_timer=\$DB_${DB}_ELECTION_TIMER
+eval relay_mode=\$RELAY_MODE
+eval relay_remote=\$DB_${DB}_REMOTE
ovn_install_dir "$OVN_RUNDIR"
ovn_install_dir "$ovn_logdir"
@@ -222,6 +229,8 @@ start_ovsdb__() {
mode=active_passive
echo "$sync_from_proto:$sync_from_addr:\
$sync_from_port" > $active_conf_file
+elif test X"$relay_mode" != Xno; then
+mode=relay
else
mode=standalone
fi
@@ -245,6 +254,8 @@ $cluster_remote_port
else
create_cluster "$file" "$schema" "$local" "$ovn_db_election_timer"
fi
+elif test $mode = relay; then
+local file="relay:${schema_name}:${relay_remote}"
else
upgrade_db "$file" "$schema"
fi
@@ -332,7 +343,7 @@ $cluster_remote_port
fi
# Initialize the database if it's NOT joining a cluster.
-if test -z "$cluster_remote_addr"; then
+if test -z "$cluster_remote_addr" && test X$mode != Xrelay; then
$(echo ovn-${db}ctl | tr _ -) --no-leader-only --db="unix:$sock" init
fi
@@ -349,6 +360,11 @@ start_nb_ovsdb() {
start_ovsdb__ NB nb OVN_Northbound NB_Global "$OVSDB_NB_WRAPPER"
}
+start_sb_relay_ovsdb() {
+RELAY_MODE=yes
+start_ovsdb__ SB_RELAY sb-relay OVN_Southbound SB_Global
+}
+
start_sb_ovsdb() {
# Increase the limit on the number of open file descriptors, because
# SB DB may connect to large number of chassises, on top of connections
@@ -694,6 +710,11 @@ restart_ic_sb_ovsdb () {
start_ic_sb_ovsdb
}
+restart_sb_relay_ovsdb() {
+stop_sb_relay_ovsdb
+start_sb_relay_ovsdb
+}
+
## ##
## main ##
## ##
@@ -785,6 +806,8 @@ set_defaults () {
OVN_IC_SB_LOG="-vconsole:off -vfile:info"
OVN_IC_NB_LOGFILE="$ovn_logdir/ovsdb-server-ic-nb.log"
OVN_IC_SB_LOGFILE="$ovn_logdir/ovsdb-server-ic-sb.log"
+OVN_SB_RELAY_LOG="-vconsole:emer -vsyslog:err -vfile:info"
+OVN_SB_RELAY_LOGFILE="$ovn_logdir/ovsdb-server-sb-relay.log"
OVN_CONTROLLER_SSL_KEY=""
OVN_CONTROLLER_SSL_CERT=""
@@ -867,6 +890,15 @@ set_defaults () {
OVN_IC_SB_DB_SSL_CERT=""
OVN_IC_SB_DB_SSL_CA_CERT=""
+RELAY_MODE=no
+DB_SB_RELAY_REMOTE=
+DB_SB_RELAY_SOCK=$OVN_RUNDIR/ovnsb_relay_db.sock
+DB_SB_RELAY_PIDFILE=$OVN_RUNDIR/ovnsb_relay_db.pid
+DB_SB_RELAY_CTRL_SOCK=$OVN_RUNDIR/ovnsb_relay_db.ctl
+OVN_SB_RELAY_DB_SSL_KEY=""
+OVN_SB_RELAY_DB_SSL_CERT=""
+OVN_SB_RELAY_DB_SSL_CA_CERT=""
+DB_SB_RELAY_USE_REMOTE_IN_DB="yes"
}
set_option () {
@@ -902,6 +934,7 @@ Commands:
start_ic_sb_ovsdb start ovn ic-southbound db ovsdb-server process
start_controllerstart ovn-controller
start_controller_vtep start ovn-controller-vtep
+ start_sb_relay_ovsdb
[ovs-dev] [PATCH ovn v3 2/4] rhel: add ovn-db@.service systemd-unit
With this universal systemd unit users, which run ovsdb-servers with
systemd, will be able to run different OVSDB server instances within
separate systemd-units.
Now it is possible to run all commands from ovn-ctl script, which start
and end with "start_/stop_" and "_ovsdb" respectively. Current list is:
- ovn-db@sb
- ovn-db@nb
- ovn-db@ic
- ovn-db@ic_sb
- ovn-db@ic_nb
- ovn-db@sb_relay
And any possible future commands, which conform rules described above.
To run such units user must define environment variable, which name
has a next form: "ovn_%i_opts". Where %i is the name of unit instance
(a part after "@" symbol). User may supply this variable with
configuration parameter in one of /etc/sysconfig/ovn,
/etc/sysconfig/ovn-%i or in
/etc/systemd/system/ovn-db@%i.service.d/local.conf files.
In general this feature gives more granular process management. For
instance, it is not needed to restart SB and NB ovsdb-servers anymore,
when user just restarts ovn-northd daemon (upgrade scenario).
Signed-off-by: Vladislav Odintsov
Reviewed-by: Ales Musil
---
NEWS| 2 ++
rhel/automake.mk| 1 +
rhel/ovn-fedora.spec.in | 31 +++-
rhel/usr_lib_systemd_system_ovn-db@.service | 39 +
4 files changed, 72 insertions(+), 1 deletion(-)
create mode 100644 rhel/usr_lib_systemd_system_ovn-db@.service
diff --git a/NEWS b/NEWS
index 9aeeac10b..fd0fee75c 100644
--- a/NEWS
+++ b/NEWS
@@ -3,6 +3,8 @@ Post v22.12.0
- ovn-controller: Experimental support for co-hosting multiple controller
instances on the same host.
- Add ovn-ctl commands for (re)starting/stopping OVSDB relay for OVN SB DB.
+ - Add new ovn-db@.service systemd unit to run ovsdb-servers in separate
+systemd units.
OVN v22.12.0 - 16 Dec 2022
--
diff --git a/rhel/automake.mk b/rhel/automake.mk
index 3e71f5d80..992de3dc7 100644
--- a/rhel/automake.mk
+++ b/rhel/automake.mk
@@ -13,6 +13,7 @@ EXTRA_DIST += \
rhel/ovn-fedora.spec.in \
rhel/usr_lib_systemd_system_ovn-controller.service \
rhel/usr_lib_systemd_system_ovn-controller-vtep.service \
+ rhel/usr_lib_systemd_system_ovn-db@.service \
rhel/usr_lib_systemd_system_ovn-ic.service \
rhel/usr_lib_systemd_system_ovn-ic-db.service \
rhel/usr_lib_systemd_system_ovn-northd.service \
diff --git a/rhel/ovn-fedora.spec.in b/rhel/ovn-fedora.spec.in
index 57dc977c1..03c1f27c5 100644
--- a/rhel/ovn-fedora.spec.in
+++ b/rhel/ovn-fedora.spec.in
@@ -165,7 +165,7 @@ install -p -D -m 0644 \
rhel/usr_share_ovn_scripts_systemd_sysconfig.template \
$RPM_BUILD_ROOT/%{_sysconfdir}/sysconfig/ovn
-for service in ovn-controller ovn-controller-vtep ovn-northd ovn-ic ovn-ic-db;
do
+for service in ovn-controller ovn-controller-vtep ovn-northd ovn-ic ovn-ic-db
ovn-db@; do
install -p -D -m 0644 \
rhel/usr_lib_systemd_system_${service}.service \
$RPM_BUILD_ROOT%{_unitdir}/${service}.service
@@ -265,6 +265,17 @@ if [ $1 -eq 1 ] ; then
fi
fi
+%preun
+%if 0%{?systemd_preun:1}
+%systemd_preun ovn-db@*.service
+%else
+if [ $1 -eq 0 ] ; then
+# Package removal, not upgrade
+/bin/systemctl --no-reload disable ovn-db@*.service >/dev/null 2>&1 ||
:
+/bin/systemctl stop ovn-db@*.service >/dev/null 2>&1 || :
+fi
+%endif
+
%preun central
%if 0%{?systemd_preun:1}
%systemd_preun ovn-northd.service
@@ -328,6 +339,15 @@ if [ $1 -eq 1 ]; then
fi
%endif
+%if 0%{?systemd_post:1}
+%systemd_post ovn-db@*.service
+%else
+# Package install, not upgrade
+if [ $1 -eq 1 ]; then
+/bin/systemctl daemon-reload >dev/null || :
+fi
+%endif
+
%post central
%if 0%{?systemd_post:1}
%systemd_post ovn-northd.service
@@ -377,6 +397,11 @@ fi
%endif
%postun
+%if 0%{?systemd_postun:1}
+%systemd_postun ovn-db@*.service
+%else
+/bin/systemctl daemon-reload >/dev/null 2>&1 || :
+%endif
%postun central
%if 0%{?systemd_postun_with_restart:1}
@@ -492,6 +517,7 @@ fi
%{_mandir}/man5/ovn-ic-sb.5*
%{_prefix}/lib/ocf/resource.d/ovn/ovndb-servers
%config(noreplace) %{_sysconfdir}/logrotate.d/ovn
+%{_unitdir}/ovn-db@.service
%files docker
%{_bindir}/ovn-docker-overlay-driver
@@ -522,6 +548,9 @@ fi
%{_unitdir}/ovn-controller-vtep.service
%changelog
+* Wed Jan 11 2023 Vladislav Odintsov
+- Added ovn-db@.service systemd-unit.
+
* Mon Feb 1 2021 Vladislav Odintsov
- Added ovn-ic, ovn-ic-db systemd-units.
diff --git a/rhel/usr_lib_systemd_system_ovn-db@.service
b/rhel/usr_lib_systemd_system_ovn-db@.service
new file mode 100644
index 0..98556a673
--- /dev/null
+++ b/rhel/usr_lib_systemd_system_ovn-db@.service
@@ -0,0 +1,39 @@
+# This system unit is used to manage OVN DB daemons.
+# It supports
[ovs-dev] [PATCH ovn v3 0/4] Add support for OVSDB Relay in OVN SB DB
v2->v3: - Address Dumitru's comment regarding wrong %systemd_postun rpm macro usage. - Rebase on current main branch. v1->v2: - Added post/preun/postun scripts to manage systemd-related logic around new service unit. This patch series adds support to run utilize OVSDB Relay functionality in OVN: - add new commands to ovn-ctl script - add new systemd-unit ovn-db@.service to manage ovsdb-servers - add support to run against non-leader to ovn-controller-vtep - add documentation about OVSDB Relay usage in OVN Vladislav Odintsov (4): rhel,ovn-ctl: add support to run OVN SB relay rhel: add ovn-db@.service systemd-unit vtep: set SB DB ovsdb_idl to no_leader_only mode docs: add tutorial for ovsdb relay usage Documentation/automake.mk | 4 + .../tutorials/images/ovsdb-relay-1.png| Bin 0 -> 68086 bytes .../tutorials/images/ovsdb-relay-2.png| Bin 0 -> 84019 bytes .../tutorials/images/ovsdb-relay-3.png| Bin 0 -> 116547 bytes Documentation/tutorials/index.rst | 1 + Documentation/tutorials/ovn-ovsdb-relay.rst | 265 ++ Documentation/tutorials/ovn-rbac.rst | 2 + NEWS | 3 + controller-vtep/ovn-controller-vtep.c | 1 + rhel/automake.mk | 1 + rhel/ovn-fedora.spec.in | 31 +- rhel/usr_lib_systemd_system_ovn-db@.service | 39 +++ utilities/ovn-ctl | 56 +++- 13 files changed, 401 insertions(+), 2 deletions(-) create mode 100644 Documentation/tutorials/images/ovsdb-relay-1.png create mode 100644 Documentation/tutorials/images/ovsdb-relay-2.png create mode 100644 Documentation/tutorials/images/ovsdb-relay-3.png create mode 100644 Documentation/tutorials/ovn-ovsdb-relay.rst create mode 100644 rhel/usr_lib_systemd_system_ovn-db@.service -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn 1/2] northd: make traffic routed to vtep lport distributed
Hi Simon,
thanks for the review.
I agree with all your comments and I’ll address them in v2.
Regards,
Vladislav Odintsov
> On 18 Jan 2023, at 16:08, Simon Horman wrote:
>
> On Thu, Dec 22, 2022 at 08:43:08PM +0300, Vladislav Odintsov wrote:
>> There were two issues prior to this patch:
>> 1. It was unable to have connectivity to networks over a router in
>> physical network connected through VTEP (ramp) gateway.
>> Consider next topology:
>>
>> ovn-nbctl lr-add lr1
>> ovn-nbctl lrp-add lr1 lrp1 00:00:00:00:00:01 10.0.0.1/24
>> ovn-nbctl ls-add ls1
>> ovn-nbctl lrp-add ls1 lsp1 -- \
>> lsp-set-addresses lsp1 router -- \
>> lsp-set-type lsp1 router -- \
>> lsp-set-options lsp1 router-port=lrp1
>> ovn-nbctl lsp-add ls1 lsp-vtep -- \
>> lsp-set-type lsp-vtep vtep -- \
>> lsp-set-addresses lsp-vtep unknown -- \
>> lsp-set-options lsp-vtep vtep-physical-switch=<..>
>> vtep-logical-switch=<..>
>> ovn-nbctl lr-route-add lr1 192.168.0.0/24 10.0.0.100
>>
>> If one issues ping from lsp1 to some address from 192.168.0.0/24 (via
>> vtep lsp), to enable routing support with vtep it is required to set
>> redirect chassis or ha chassis group on lrp1. This topology didn't
>> provide connectivity. Now such traffic flow will work properly.
>>
>> 2. Traffic from lport in one subnet to vtep lport in another subnet of
>> same LR previously traversed via l3gw chassis, now in 'to vtep lport'
>> direction goes directly from hypervisor handling lport to VTEP (RAMP)
>> switch. In the opposite direction traffic still goes from VTEP (RAMP)
>> switch through l3gw chassis and then to hypervisor.
>
> I think it would be good to explain how the logic changes
> addresses these problems. And breifly describe which tests have been added.
>
>>
>> Signed-off-by: Vladislav Odintsov
>> ---
>> northd/northd.c | 16 +++-
>> tests/ovn-northd.at | 26 +-
>> 2 files changed, 40 insertions(+), 2 deletions(-)
>>
>> diff --git a/northd/northd.c b/northd/northd.c
>> index 4751feab4..07fb0ab9a 100644
>> --- a/northd/northd.c
>> +++ b/northd/northd.c
>> @@ -3362,7 +3362,12 @@ ovn_port_update_sbrec(struct northd_input *input_data,
>> }
>> smap_add(&new, "distributed-port", op->nbrp->name);
>>
>> -bool always_redirect = !op->od->has_distributed_nat;
>> +bool always_redirect = !(
>> +op->od->has_distributed_nat ||
>> +(op->l3dgw_port->peer &&
>> + op->l3dgw_port->peer->od->has_vtep_lports)
>> +);
>
> This seems slightly easier on my brain:
>
>bool always_redirect =
>!op->od->has_distributed_nat &&
>!(op->l3dgw_port->peer &&
> op->l3dgw_port->peer->od->has_vtep_lports)
>
>> +
>> if (redirect_type) {
>> smap_add(&new, "redirect-type", redirect_type);
>> /* XXX Why can't we enable always-redirect when redirect-type
>> @@ -12815,6 +12820,15 @@ build_gateway_redirect_flows_for_lrouter(
>> return;
>> }
>> for (size_t i = 0; i < od->n_l3dgw_ports; i++) {
>> +if (od->l3dgw_ports[i]->peer &&
>> +od->l3dgw_ports[i]->peer->od->has_vtep_lports) {
>
> This condition appears twice in this patch.
> Perhaps a helper would make its meaning more obvious.
>
>> +/* Skip adding redirect rule for vtep-enabled l3dgw ports.
>> + Traffic from hypervisor to VTEP (ramp) switch should go in
>> + distributed manner. Only returning routed traffic must go
>> + through centralized gateway (or ha-chassis-group). */
>
> nit:
> /* Multi-line comments
> * look like this. */
>
>> +continue;
>> +}
>> +
>> const struct ovsdb_idl_row *stage_hint = NULL;
>> bool add_def_flow = true;
>>
>
> ...
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v2 2/4] rhel: add ovn-db@.service systemd-unit
Hi Dumitru,
regards,
Vladislav Odintsov
> On 20 Jan 2023, at 22:51, Dumitru Ceara wrote:
>
> On 1/20/23 10:51, Ales Musil wrote:
>> On Sat, Jan 14, 2023 at 10:28 AM Vladislav Odintsov
>> wrote:
>>
>>> With this universal systemd unit users, which run ovsdb-servers with
>>> systemd, will be able to run different OVSDB server instances within
>>> separate systemd-units.
>>>
>>> Now it is possible to run all commands from ovn-ctl script, which start
>>> and end with "start_/stop_" and "_ovsdb" respectively. Current list is:
>>>
>>> - ovn-db@sb
>>> - ovn-db@nb
>>> - ovn-db@ic
>>> - ovn-db@ic_sb
>>> - ovn-db@ic_nb
>>> - ovn-db@sb_relay
>>>
>>> And any possible future commands, which conform rules described above.
>>>
>>> To run such units user must define environment variable, which name
>>> has a next form: "ovn_%i_opts". Where %i is the name of unit instance
>>> (a part after "@" symbol). User may supply this variable with
>>> configuration parameter in one of /etc/sysconfig/ovn,
>>> /etc/sysconfig/ovn-%i or in
>>> /etc/systemd/system/ovn-db@%i.service.d/local.conf files.
>>>
>>> In general this feature gives more granular process management. For
>>> instance, it is not needed to restart SB and NB ovsdb-servers anymore,
>>> when user just restarts ovn-northd daemon (upgrade scenario).
>>>
>>> Signed-off-by: Vladislav Odintsov
>>> ---
>
> Hi Vladislav,
>
>>> NEWS| 2 ++
>>> rhel/automake.mk| 1 +
>>> rhel/ovn-fedora.spec.in | 31 +++-
>>> rhel/usr_lib_systemd_system_ovn-db@.service | 39 +
>>> 4 files changed, 72 insertions(+), 1 deletion(-)
>>> create mode 100644 rhel/usr_lib_systemd_system_ovn-db@.service
>>>
>>> diff --git a/NEWS b/NEWS
>>> index 9aeeac10b..fd0fee75c 100644
>>> --- a/NEWS
>>> +++ b/NEWS
>>> @@ -3,6 +3,8 @@ Post v22.12.0
>>> - ovn-controller: Experimental support for co-hosting multiple
>>> controller
>>> instances on the same host.
>>> - Add ovn-ctl commands for (re)starting/stopping OVSDB relay for OVN SB
>>> DB.
>>> + - Add new ovn-db@.service systemd unit to run ovsdb-servers in separate
>>> +systemd units.
>>>
>>> OVN v22.12.0 - 16 Dec 2022
>>> --
>>> diff --git a/rhel/automake.mk b/rhel/automake.mk
>>> index 3e71f5d80..992de3dc7 100644
>>> --- a/rhel/automake.mk
>>> +++ b/rhel/automake.mk
>>> @@ -13,6 +13,7 @@ EXTRA_DIST += \
>>>rhel/ovn-fedora.spec.in \
>>>rhel/usr_lib_systemd_system_ovn-controller.service \
>>>rhel/usr_lib_systemd_system_ovn-controller-vtep.service \
>>> + rhel/usr_lib_systemd_system_ovn-db@.service \
>>>rhel/usr_lib_systemd_system_ovn-ic.service \
>>>rhel/usr_lib_systemd_system_ovn-ic-db.service \
>>>rhel/usr_lib_systemd_system_ovn-northd.service \
>>> diff --git a/rhel/ovn-fedora.spec.in b/rhel/ovn-fedora.spec.in
>>> index 57dc977c1..b41ad062f 100644
>>> --- a/rhel/ovn-fedora.spec.in
>>> +++ b/rhel/ovn-fedora.spec.in
>>> @@ -165,7 +165,7 @@ install -p -D -m 0644 \
>>> rhel/usr_share_ovn_scripts_systemd_sysconfig.template \
>>> $RPM_BUILD_ROOT/%{_sysconfdir}/sysconfig/ovn
>>>
>>> -for service in ovn-controller ovn-controller-vtep ovn-northd ovn-ic
>>> ovn-ic-db; do
>>> +for service in ovn-controller ovn-controller-vtep ovn-northd ovn-ic
>>> ovn-ic-db ovn-db@; do
>>> install -p -D -m 0644 \
>>> rhel/usr_lib_systemd_system_${service}.service \
>>> $RPM_BUILD_ROOT%{_unitdir}/${service}.service
>>> @@ -265,6 +265,17 @@ if [ $1 -eq 1 ] ; then
>>> fi
>>> fi
>>>
>>> +%preun
>>> +%if 0%{?systemd_preun:1}
>>> +%systemd_preun ovn-db@*.service
>>> +%else
>>> +if [ $1 -eq 0 ] ; then
>>> +# Package removal, not upgrade
>>> +/bin/systemctl --no-reload disable ovn-db@*.service >/dev/null
>>> 2>&1 || :
>>> +/bin/systemctl stop ovn-db@*.service >/dev/null 2>&1 || :
>>> +fi
>>> +%endif
>>> +
>>> %preun cen
Re: [ovs-dev] [PATCH ovn] controller-vtep: monitor only needed SB tables
Hi Dumitru, yes, it was based on my OVSDB Relay support series, I thought it would be accepted first :) Thanks! Regards, Vladislav Odintsov > On 17 Jan 2023, at 19:11, Dumitru Ceara wrote: > > On 1/13/23 21:03, Vladislav Odintsov wrote: >> Signed-off-by: Vladislav Odintsov >> --- >> controller-vtep/ovn-controller-vtep.c | 33 ++- >> 1 file changed, 32 insertions(+), 1 deletion(-) >> >> diff --git a/controller-vtep/ovn-controller-vtep.c >> b/controller-vtep/ovn-controller-vtep.c >> index df20816ff..26f8fd115 100644 >> --- a/controller-vtep/ovn-controller-vtep.c >> +++ b/controller-vtep/ovn-controller-vtep.c >> @@ -122,7 +122,38 @@ main(int argc, char *argv[]) >> >> /* Connect to OVN SB database. */ >> struct ovsdb_idl_loop ovnsb_idl_loop = OVSDB_IDL_LOOP_INITIALIZER( >> -ovsdb_idl_create(ovnsb_remote, &sbrec_idl_class, true, true)); >> +ovsdb_idl_create(ovnsb_remote, &sbrec_idl_class, false, true)); >> + >> +ovsdb_idl_add_table(ovnsb_idl_loop.idl, &sbrec_table_sb_global); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_sb_global_col_options); >> + >> +ovsdb_idl_add_table(ovnsb_idl_loop.idl, &sbrec_table_chassis); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_chassis_col_encaps); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_chassis_col_name); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, >> &sbrec_chassis_col_other_config); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, >> + &sbrec_chassis_col_vtep_logical_switches); >> + >> +ovsdb_idl_add_table(ovnsb_idl_loop.idl, &sbrec_table_encap); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_encap_col_chassis_name); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_encap_col_ip); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_encap_col_options); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_encap_col_type); >> + >> +ovsdb_idl_add_table(ovnsb_idl_loop.idl, &sbrec_table_datapath_binding); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, >> + &sbrec_datapath_binding_col_tunnel_key); >> + >> +ovsdb_idl_add_table(ovnsb_idl_loop.idl, &sbrec_table_port_binding); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, >> &sbrec_port_binding_col_chassis); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, >> &sbrec_port_binding_col_datapath); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, >> + &sbrec_port_binding_col_logical_port); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_port_binding_col_mac); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, >> &sbrec_port_binding_col_options); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_port_binding_col_type); >> +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_port_binding_col_up); >> + >> ovsdb_idl_set_leader_only(ovnsb_idl_loop.idl, false); > > Hi Vladislav, > > This is based on a not-yet accepted patch, that's why 0day-robot failed > to apply it. I adapted the patch, removing this line, and applied it to > the main branch. > > Thanks, > Dumitru > >> ovsdb_idl_get_initial_snapshot(ovnsb_idl_loop.idl); >> > > ___ > dev mailing list > d...@openvswitch.org <mailto:d...@openvswitch.org> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn 0/4] Add support for OVSDB Relay in OVN SB DB
This series was superseded by a new v2: https://patchwork.ozlabs.org/project/ovn/cover/20230114092808.3538014-1-odiv...@gmail.com/ Regards, Vladislav Odintsov > On 6 Jan 2023, at 02:33, Vladislav Odintsov wrote: > > This patch series adds support to run utilize OVSDB Relay functionality in > OVN: > - add new commands to ovn-ctl script > - add new systemd-unit ovn-db@.service to manage ovsdb-servers > - add support to run against non-leader to ovn-controller-vtep > - add documentation about OVSDB Relay usage in OVN > > Vladislav Odintsov (4): > rhel,ovn-ctl: add support to run OVN SB relay > rhel: add ovn-db@.service systemd-unit > vtep: set SB DB ovsdb_idl to no_leader_only mode > docs: add tutorial for ovsdb relay usage > > Documentation/automake.mk | 4 + > .../tutorials/images/ovsdb-relay-1.png| Bin 0 -> 68086 bytes > .../tutorials/images/ovsdb-relay-2.png| Bin 0 -> 84019 bytes > .../tutorials/images/ovsdb-relay-3.png| Bin 0 -> 116547 bytes > Documentation/tutorials/index.rst | 1 + > Documentation/tutorials/ovn-ovsdb-relay.rst | 265 ++ > Documentation/tutorials/ovn-rbac.rst | 2 + > NEWS | 3 + > controller-vtep/ovn-controller-vtep.c | 1 + > rhel/automake.mk | 1 + > rhel/ovn-fedora.spec.in | 3 +- > rhel/usr_lib_systemd_system_ovn-db@.service | 39 +++ > utilities/ovn-ctl | 56 +++- > 13 files changed, 373 insertions(+), 2 deletions(-) > create mode 100644 Documentation/tutorials/images/ovsdb-relay-1.png > create mode 100644 Documentation/tutorials/images/ovsdb-relay-2.png > create mode 100644 Documentation/tutorials/images/ovsdb-relay-3.png > create mode 100644 Documentation/tutorials/ovn-ovsdb-relay.rst > create mode 100644 rhel/usr_lib_systemd_system_ovn-db@.service > > -- > 2.36.1 > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn v2 1/4] rhel, ovn-ctl: add support to run OVN SB relay
New ovn-ctl commands were added:
- start_sb_relay_ovsdb
- stop_sb_relay_ovsdb
- restart_sb_relay_ovsdb
Required configuration parameters are:
--db-sb-relay-remote - needed to supply upstream cluster/server remote.
Optionally user may pass next parameters:
--db-sb-relay-sock
--db-sb-relay-pidfile
--db-sb-relay-ctrl-sock
--db-sb-relay-use-remote-in-db
--ovn-sb-relay-db-ssl-key
--ovn-sb-relay-db-ssl-cert
--ovn-sb-relay-db-ssl-ca-cert
Signed-off-by: Vladislav Odintsov
---
NEWS | 1 +
utilities/ovn-ctl | 56 ++-
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/NEWS b/NEWS
index 2e0d54ae6..9aeeac10b 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,7 @@ Post v22.12.0
-
- ovn-controller: Experimental support for co-hosting multiple controller
instances on the same host.
+ - Add ovn-ctl commands for (re)starting/stopping OVSDB relay for OVN SB DB.
OVN v22.12.0 - 16 Dec 2022
--
diff --git a/utilities/ovn-ctl b/utilities/ovn-ctl
index 93be9b84b..dc8865abf 100755
--- a/utilities/ovn-ctl
+++ b/utilities/ovn-ctl
@@ -84,6 +84,10 @@ stop_ic_ovsdb () {
stop_ic_sb_ovsdb
}
+stop_sb_relay_ovsdb() {
+OVS_RUNDIR=${OVS_RUNDIR} stop_ovn_daemon ovnsb_relay $DB_SB_RELAY_PIDFILE
$DB_SB_RELAY_CTRL_SOCK
+}
+
demote_xx_ovsdb () {
local sync_from_addr=$1
local sync_from_proto=$2
@@ -179,6 +183,7 @@ start_ovsdb__() {
local ovn_db_ssl_cert
local ovn_db_ssl_cacert
local ovn_db_election_timer
+local relay_mode
eval db_pid_file=\$DB_${DB}_PIDFILE
eval cluster_local_addr=\$DB_${DB}_CLUSTER_LOCAL_ADDR
eval cluster_local_port=\$DB_${DB}_CLUSTER_LOCAL_PORT
@@ -205,6 +210,8 @@ start_ovsdb__() {
eval ovn_db_ssl_cert=\$OVN_${DB}_DB_SSL_CERT
eval ovn_db_ssl_cacert=\$OVN_${DB}_DB_SSL_CA_CERT
eval ovn_db_election_timer=\$DB_${DB}_ELECTION_TIMER
+eval relay_mode=\$RELAY_MODE
+eval relay_remote=\$DB_${DB}_REMOTE
ovn_install_dir "$OVN_RUNDIR"
ovn_install_dir "$ovn_logdir"
@@ -222,6 +229,8 @@ start_ovsdb__() {
mode=active_passive
echo "$sync_from_proto:$sync_from_addr:\
$sync_from_port" > $active_conf_file
+elif test X"$relay_mode" != Xno; then
+mode=relay
else
mode=standalone
fi
@@ -245,6 +254,8 @@ $cluster_remote_port
else
create_cluster "$file" "$schema" "$local" "$ovn_db_election_timer"
fi
+elif test $mode = relay; then
+local file="relay:${schema_name}:${relay_remote}"
else
upgrade_db "$file" "$schema"
fi
@@ -332,7 +343,7 @@ $cluster_remote_port
fi
# Initialize the database if it's NOT joining a cluster.
-if test -z "$cluster_remote_addr"; then
+if test -z "$cluster_remote_addr" && test X$mode != Xrelay; then
$(echo ovn-${db}ctl | tr _ -) --no-leader-only --db="unix:$sock" init
fi
@@ -349,6 +360,11 @@ start_nb_ovsdb() {
start_ovsdb__ NB nb OVN_Northbound NB_Global "$OVSDB_NB_WRAPPER"
}
+start_sb_relay_ovsdb() {
+RELAY_MODE=yes
+start_ovsdb__ SB_RELAY sb-relay OVN_Southbound SB_Global
+}
+
start_sb_ovsdb() {
# Increase the limit on the number of open file descriptors, because
# SB DB may connect to large number of chassises, on top of connections
@@ -694,6 +710,11 @@ restart_ic_sb_ovsdb () {
start_ic_sb_ovsdb
}
+restart_sb_relay_ovsdb() {
+stop_sb_relay_ovsdb
+start_sb_relay_ovsdb
+}
+
## ##
## main ##
## ##
@@ -785,6 +806,8 @@ set_defaults () {
OVN_IC_SB_LOG="-vconsole:off -vfile:info"
OVN_IC_NB_LOGFILE="$ovn_logdir/ovsdb-server-ic-nb.log"
OVN_IC_SB_LOGFILE="$ovn_logdir/ovsdb-server-ic-sb.log"
+OVN_SB_RELAY_LOG="-vconsole:emer -vsyslog:err -vfile:info"
+OVN_SB_RELAY_LOGFILE="$ovn_logdir/ovsdb-server-sb-relay.log"
OVN_CONTROLLER_SSL_KEY=""
OVN_CONTROLLER_SSL_CERT=""
@@ -867,6 +890,15 @@ set_defaults () {
OVN_IC_SB_DB_SSL_CERT=""
OVN_IC_SB_DB_SSL_CA_CERT=""
+RELAY_MODE=no
+DB_SB_RELAY_REMOTE=
+DB_SB_RELAY_SOCK=$OVN_RUNDIR/ovnsb_relay_db.sock
+DB_SB_RELAY_PIDFILE=$OVN_RUNDIR/ovnsb_relay_db.pid
+DB_SB_RELAY_CTRL_SOCK=$OVN_RUNDIR/ovnsb_relay_db.ctl
+OVN_SB_RELAY_DB_SSL_KEY=""
+OVN_SB_RELAY_DB_SSL_CERT=""
+OVN_SB_RELAY_DB_SSL_CA_CERT=""
+DB_SB_RELAY_USE_REMOTE_IN_DB="yes"
}
set_option () {
@@ -902,6 +934,7 @@ Commands:
start_ic_sb_ovsdb start ovn ic-southbound db ovsdb-server process
start_controllerstart ovn-controller
start_controller_vtep start ovn-controller-vtep
+ start_sb_relay_ovsdbstart ovn southbound db ovsdb-server
[ovs-dev] [PATCH ovn v2 2/4] rhel: add ovn-db@.service systemd-unit
With this universal systemd unit users, which run ovsdb-servers with
systemd, will be able to run different OVSDB server instances within
separate systemd-units.
Now it is possible to run all commands from ovn-ctl script, which start
and end with "start_/stop_" and "_ovsdb" respectively. Current list is:
- ovn-db@sb
- ovn-db@nb
- ovn-db@ic
- ovn-db@ic_sb
- ovn-db@ic_nb
- ovn-db@sb_relay
And any possible future commands, which conform rules described above.
To run such units user must define environment variable, which name
has a next form: "ovn_%i_opts". Where %i is the name of unit instance
(a part after "@" symbol). User may supply this variable with
configuration parameter in one of /etc/sysconfig/ovn,
/etc/sysconfig/ovn-%i or in
/etc/systemd/system/ovn-db@%i.service.d/local.conf files.
In general this feature gives more granular process management. For
instance, it is not needed to restart SB and NB ovsdb-servers anymore,
when user just restarts ovn-northd daemon (upgrade scenario).
Signed-off-by: Vladislav Odintsov
---
NEWS| 2 ++
rhel/automake.mk| 1 +
rhel/ovn-fedora.spec.in | 31 +++-
rhel/usr_lib_systemd_system_ovn-db@.service | 39 +
4 files changed, 72 insertions(+), 1 deletion(-)
create mode 100644 rhel/usr_lib_systemd_system_ovn-db@.service
diff --git a/NEWS b/NEWS
index 9aeeac10b..fd0fee75c 100644
--- a/NEWS
+++ b/NEWS
@@ -3,6 +3,8 @@ Post v22.12.0
- ovn-controller: Experimental support for co-hosting multiple controller
instances on the same host.
- Add ovn-ctl commands for (re)starting/stopping OVSDB relay for OVN SB DB.
+ - Add new ovn-db@.service systemd unit to run ovsdb-servers in separate
+systemd units.
OVN v22.12.0 - 16 Dec 2022
--
diff --git a/rhel/automake.mk b/rhel/automake.mk
index 3e71f5d80..992de3dc7 100644
--- a/rhel/automake.mk
+++ b/rhel/automake.mk
@@ -13,6 +13,7 @@ EXTRA_DIST += \
rhel/ovn-fedora.spec.in \
rhel/usr_lib_systemd_system_ovn-controller.service \
rhel/usr_lib_systemd_system_ovn-controller-vtep.service \
+ rhel/usr_lib_systemd_system_ovn-db@.service \
rhel/usr_lib_systemd_system_ovn-ic.service \
rhel/usr_lib_systemd_system_ovn-ic-db.service \
rhel/usr_lib_systemd_system_ovn-northd.service \
diff --git a/rhel/ovn-fedora.spec.in b/rhel/ovn-fedora.spec.in
index 57dc977c1..b41ad062f 100644
--- a/rhel/ovn-fedora.spec.in
+++ b/rhel/ovn-fedora.spec.in
@@ -165,7 +165,7 @@ install -p -D -m 0644 \
rhel/usr_share_ovn_scripts_systemd_sysconfig.template \
$RPM_BUILD_ROOT/%{_sysconfdir}/sysconfig/ovn
-for service in ovn-controller ovn-controller-vtep ovn-northd ovn-ic ovn-ic-db;
do
+for service in ovn-controller ovn-controller-vtep ovn-northd ovn-ic ovn-ic-db
ovn-db@; do
install -p -D -m 0644 \
rhel/usr_lib_systemd_system_${service}.service \
$RPM_BUILD_ROOT%{_unitdir}/${service}.service
@@ -265,6 +265,17 @@ if [ $1 -eq 1 ] ; then
fi
fi
+%preun
+%if 0%{?systemd_preun:1}
+%systemd_preun ovn-db@*.service
+%else
+if [ $1 -eq 0 ] ; then
+# Package removal, not upgrade
+/bin/systemctl --no-reload disable ovn-db@*.service >/dev/null 2>&1 ||
:
+/bin/systemctl stop ovn-db@*.service >/dev/null 2>&1 || :
+fi
+%endif
+
%preun central
%if 0%{?systemd_preun:1}
%systemd_preun ovn-northd.service
@@ -328,6 +339,15 @@ if [ $1 -eq 1 ]; then
fi
%endif
+%if 0%{?systemd_post:1}
+%systemd_post ovn-db@*.service
+%else
+# Package install, not upgrade
+if [ $1 -eq 1 ]; then
+/bin/systemctl daemon-reload >dev/null || :
+fi
+%endif
+
%post central
%if 0%{?systemd_post:1}
%systemd_post ovn-northd.service
@@ -377,6 +397,11 @@ fi
%endif
%postun
+%if 0%{?systemd_postun:1}
+%systemd_postun
+%else
+/bin/systemctl daemon-reload >/dev/null 2>&1 || :
+%endif
%postun central
%if 0%{?systemd_postun_with_restart:1}
@@ -492,6 +517,7 @@ fi
%{_mandir}/man5/ovn-ic-sb.5*
%{_prefix}/lib/ocf/resource.d/ovn/ovndb-servers
%config(noreplace) %{_sysconfdir}/logrotate.d/ovn
+%{_unitdir}/ovn-db@.service
%files docker
%{_bindir}/ovn-docker-overlay-driver
@@ -522,6 +548,9 @@ fi
%{_unitdir}/ovn-controller-vtep.service
%changelog
+* Wed Jan 11 2023 Vladislav Odintsov
+- Added ovn-db@.service systemd-unit.
+
* Mon Feb 1 2021 Vladislav Odintsov
- Added ovn-ic, ovn-ic-db systemd-units.
diff --git a/rhel/usr_lib_systemd_system_ovn-db@.service
b/rhel/usr_lib_systemd_system_ovn-db@.service
new file mode 100644
index 0..98556a673
--- /dev/null
+++ b/rhel/usr_lib_systemd_system_ovn-db@.service
@@ -0,0 +1,39 @@
+# This system unit is used to manage OVN DB daemons.
+# It supports all '_ovsdb'-ending commands in
+
[ovs-dev] [PATCH ovn v2 3/4] vtep: set SB DB ovsdb_idl to no_leader_only mode
This adds capability to run ovn-controller-vtep against OVN Southbound OVSDB server running in relay mode. Signed-off-by: Vladislav Odintsov --- controller-vtep/ovn-controller-vtep.c | 1 + 1 file changed, 1 insertion(+) diff --git a/controller-vtep/ovn-controller-vtep.c b/controller-vtep/ovn-controller-vtep.c index 50f412b95..df20816ff 100644 --- a/controller-vtep/ovn-controller-vtep.c +++ b/controller-vtep/ovn-controller-vtep.c @@ -123,6 +123,7 @@ main(int argc, char *argv[]) /* Connect to OVN SB database. */ struct ovsdb_idl_loop ovnsb_idl_loop = OVSDB_IDL_LOOP_INITIALIZER( ovsdb_idl_create(ovnsb_remote, &sbrec_idl_class, true, true)); +ovsdb_idl_set_leader_only(ovnsb_idl_loop.idl, false); ovsdb_idl_get_initial_snapshot(ovnsb_idl_loop.idl); char *ovn_version = ovn_get_internal_version(); -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn v2 0/4] Add support for OVSDB Relay in OVN SB DB
v1->v2: - Added post/preun/postun scripts to manage systemd-related logic around new service unit. This patch series adds support to run utilize OVSDB Relay functionality in OVN: - add new commands to ovn-ctl script - add new systemd-unit ovn-db@.service to manage ovsdb-servers - add support to run against non-leader to ovn-controller-vtep - add documentation about OVSDB Relay usage in OVN Vladislav Odintsov (4): rhel,ovn-ctl: add support to run OVN SB relay rhel: add ovn-db@.service systemd-unit vtep: set SB DB ovsdb_idl to no_leader_only mode docs: add tutorial for ovsdb relay usage Documentation/automake.mk | 4 + .../tutorials/images/ovsdb-relay-1.png| Bin 0 -> 68086 bytes .../tutorials/images/ovsdb-relay-2.png| Bin 0 -> 84019 bytes .../tutorials/images/ovsdb-relay-3.png| Bin 0 -> 116547 bytes Documentation/tutorials/index.rst | 1 + Documentation/tutorials/ovn-ovsdb-relay.rst | 265 ++ Documentation/tutorials/ovn-rbac.rst | 2 + NEWS | 3 + controller-vtep/ovn-controller-vtep.c | 1 + rhel/automake.mk | 1 + rhel/ovn-fedora.spec.in | 31 +- rhel/usr_lib_systemd_system_ovn-db@.service | 39 +++ utilities/ovn-ctl | 56 +++- 13 files changed, 401 insertions(+), 2 deletions(-) create mode 100644 Documentation/tutorials/images/ovsdb-relay-1.png create mode 100644 Documentation/tutorials/images/ovsdb-relay-2.png create mode 100644 Documentation/tutorials/images/ovsdb-relay-3.png create mode 100644 Documentation/tutorials/ovn-ovsdb-relay.rst create mode 100644 rhel/usr_lib_systemd_system_ovn-db@.service -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn] controller-vtep: monitor only needed SB tables
Signed-off-by: Vladislav Odintsov --- controller-vtep/ovn-controller-vtep.c | 33 ++- 1 file changed, 32 insertions(+), 1 deletion(-) diff --git a/controller-vtep/ovn-controller-vtep.c b/controller-vtep/ovn-controller-vtep.c index df20816ff..26f8fd115 100644 --- a/controller-vtep/ovn-controller-vtep.c +++ b/controller-vtep/ovn-controller-vtep.c @@ -122,7 +122,38 @@ main(int argc, char *argv[]) /* Connect to OVN SB database. */ struct ovsdb_idl_loop ovnsb_idl_loop = OVSDB_IDL_LOOP_INITIALIZER( -ovsdb_idl_create(ovnsb_remote, &sbrec_idl_class, true, true)); +ovsdb_idl_create(ovnsb_remote, &sbrec_idl_class, false, true)); + +ovsdb_idl_add_table(ovnsb_idl_loop.idl, &sbrec_table_sb_global); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_sb_global_col_options); + +ovsdb_idl_add_table(ovnsb_idl_loop.idl, &sbrec_table_chassis); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_chassis_col_encaps); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_chassis_col_name); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_chassis_col_other_config); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, + &sbrec_chassis_col_vtep_logical_switches); + +ovsdb_idl_add_table(ovnsb_idl_loop.idl, &sbrec_table_encap); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_encap_col_chassis_name); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_encap_col_ip); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_encap_col_options); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_encap_col_type); + +ovsdb_idl_add_table(ovnsb_idl_loop.idl, &sbrec_table_datapath_binding); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, + &sbrec_datapath_binding_col_tunnel_key); + +ovsdb_idl_add_table(ovnsb_idl_loop.idl, &sbrec_table_port_binding); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_port_binding_col_chassis); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_port_binding_col_datapath); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, + &sbrec_port_binding_col_logical_port); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_port_binding_col_mac); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_port_binding_col_options); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_port_binding_col_type); +ovsdb_idl_add_column(ovnsb_idl_loop.idl, &sbrec_port_binding_col_up); + ovsdb_idl_set_leader_only(ovnsb_idl_loop.idl, false); ovsdb_idl_get_initial_snapshot(ovnsb_idl_loop.idl); -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn branch-21.06] tests: Adapt "conntrack nat implies conntrack" test for branch 21.06.
Thanks Dumitru for the patch.
It looks good to me.
Acked-by: Vladislav Odintsov
Regards,
Vladislav Odintsov
> On 11 Jan 2023, at 17:50, Dumitru Ceara wrote:
>
> Commit 384a7c6237da ("northd: Refactor Logical Flows for routers with
> DNAT/Load Balancers") changed the pipeline a bit, and started using
> ct_dnat instead of ct_next. Originally, the "conntrack nat implies
> conntrack" test was written on top of the afore mentioned change.
>
> On branch-21.06 however, we still have ct_next in the pipeline instead
> of ct_dnat. Adapt the test accordingly.
>
> Reported-at:
> https://mail.openvswitch.org/pipermail/ovs-dev/2023-January/400996.html
> Reported-by: Vladislav Odintsov
> Signed-off-by: Dumitru Ceara
> ---
> Note: This patch is only applicable to branch-21.06
> ---
> tests/ovn-northd.at | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
> index df95417fd6..b521b2dbda 100644
> --- a/tests/ovn-northd.at
> +++ b/tests/ovn-northd.at
> @@ -3748,7 +3748,7 @@ flow="eth.dst == 00:00:00:00:01:00 && inport ==
> \"rtr-ls\" && ip4.src == 42.42.4
>
> AT_CHECK_UNQUOTED([ovn-trace --ct new --minimal "${flow}" --lb-dst
> 42.42.42.42:4242], [0], [dnl
> #
> tcp,reg14=0x1,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:01:00,nw_src=42.42.42.42,nw_dst=43.43.43.43,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=0,tp_dst=4343,tcp_flags=0
> -ct_dnat /* assuming no un-dnat entry, so no change */ {
> +ct_next(ct_state=new|trk) {
> ct_lb {
> ip.ttl--;
> eth.src = 00:00:00:00:01:00;
> @@ -3766,7 +3766,9 @@ ct_dnat /* assuming no un-dnat entry, so no change */ {
>
> AT_CHECK_UNQUOTED([ovn-trace --minimal "${flow}" --lb-dst 42.42.42.42:4242],
> [0], [dnl
> #
> tcp,reg14=0x1,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:01:00,nw_src=42.42.42.42,nw_dst=43.43.43.43,nw_tos=0,nw_ecn=0,nw_ttl=64,tp_src=0,tp_dst=4343,tcp_flags=0
> -ct_dnat /* assuming no un-dnat entry, so no change */ /* default (use --ct
> to customize) */;
> +ct_next(ct_state=est|trk /* default (use --ct to customize) */) {
> +ct_dnat /* assuming no un-dnat entry, so no change */;
> +};
> ])
>
> AT_CLEANUP
> --
> 2.31.1
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn branch-20.03 3/3] ovn-ic: Only monitor useful tables and columns.
From: Dumitru Ceara Signed-off-by: Dumitru Ceara Signed-off-by: Mark Michelson Acked-by: Mark Michelson (cherry picked from commit 2698e7811b41b00ac3b6544430a95be9ae700e23) Signed-off-by: Vladislav Odintsov --- ic/ovn-ic.c | 105 +--- 1 file changed, 100 insertions(+), 5 deletions(-) diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c index 514987e02..743a4f02f 100644 --- a/ic/ovn-ic.c +++ b/ic/ovn-ic.c @@ -1609,13 +1609,108 @@ main(int argc, char *argv[]) struct ovsdb_idl_loop ovnisb_idl_loop = OVSDB_IDL_LOOP_INITIALIZER( ovsdb_idl_create(ovn_ic_sb_db, &icsbrec_idl_class, true, true)); -/* ovn-nb db. XXX: add only needed tables and columns */ +/* ovn-nb db. */ struct ovsdb_idl_loop ovnnb_idl_loop = OVSDB_IDL_LOOP_INITIALIZER( -ovsdb_idl_create(ovnnb_db, &nbrec_idl_class, true, true)); - -/* ovn-sb db. XXX: add only needed tables and columns */ +ovsdb_idl_create(ovnnb_db, &nbrec_idl_class, false, true)); + +ovsdb_idl_add_table(ovnnb_idl_loop.idl, &nbrec_table_nb_global); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, &nbrec_nb_global_col_name); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, &nbrec_nb_global_col_options); + +ovsdb_idl_add_table(ovnnb_idl_loop.idl, +&nbrec_table_logical_router_static_route); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_static_route_col_ip_prefix); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_static_route_col_nexthop); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_static_route_col_external_ids); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_static_route_col_policy); + +ovsdb_idl_add_table(ovnnb_idl_loop.idl, &nbrec_table_logical_router); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_col_name); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_col_static_routes); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_col_ports); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_col_options); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_col_external_ids); + +ovsdb_idl_add_table(ovnnb_idl_loop.idl, &nbrec_table_logical_router_port); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_port_col_name); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_port_col_networks); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_port_col_external_ids); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_port_col_options); + +ovsdb_idl_add_table(ovnnb_idl_loop.idl, &nbrec_table_logical_switch); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_col_name); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_col_ports); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_col_other_config); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_col_external_ids); + +ovsdb_idl_add_table(ovnnb_idl_loop.idl, &nbrec_table_logical_switch_port); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_name); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_addresses); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_options); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_type); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_up); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_addresses); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_enabled); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_external_ids); + +/* ovn-sb db. */ struct ovsdb_idl_loop ovnsb_idl_loop = OVSDB_IDL_LOOP_INITIALIZER( -ovsdb_idl_create(ovnsb_db, &sbrec_idl_class, true, true)); +ovsdb_idl_create(ovnsb_db, &sbrec_idl_class, false, true)); + +ovsdb_idl_add_table(ovnsb_idl_loop.idl, &sbrec_table_chassis); +ovsdb_idl_add_column(ovnsb_idl_loop.i
[ovs-dev] [PATCH ovn branch-20.03 2/3] Fix compilation issue in fedora 37/rawhide.
From: Numan Siddique Compilation is failing with the error: File "Documentation/conf.py", line 61, in with open(filename, 'rU') as f: ValueError: invalid mode: 'rU' The python 3 documentation [1] says: There is an additional mode character permitted, 'U', which no longer has any effect, and is considered deprecated. It previously enabled universal newlines in text mode, which became the default behaviour in Python 3.0. Refer to the documentation of the newline parameter for further details. [1] - https://docs.python.org/3.9/library/functions.html#open This patch fixes this issue. Acked-by: Dumitru Ceara Signed-off-by: Numan Siddique (cherry picked from commit 500982b84280fdc451877c76f5fdb9a0ac19e805) Signed-off-by: Vladislav Odintsov --- Documentation/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/conf.py b/Documentation/conf.py index 2c85dcf4d..c253e00e3 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -58,7 +58,7 @@ author = u'The Open vSwitch Development Community' # The full version, including alpha/beta/rc tags. release = None filename = "../configure.ac" -with open(filename, 'rU') as f: +with open(filename, 'r') as f: for line in f: if 'AC_INIT' in line: # Parse "AC_INIT(openvswitch, 2.7.90, b...@openvswitch.org)": -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn branch-20.03 1/3] ci: Install wheel before installing any other python packages.
From: Ilya Maximets GHA is broken due to update to pip>=22.0. This happens because now it stops backtracking packages on build failure making it impossible to find working combination of versions. We're not able to build 'hacking', because 'wheel' is not installed at that point in time. Installing it separately to fix the issue, so pip can find compatible versions of packages by backtracking. Unfortunately, new version of backtracking leads to installation of incompatible versions of flake8 and hacking. Presumably because current versions of hacking are not compatible with flake8>=4.0 and very old hacking-0.5.4 for some reason is considered suitable while resolving dependencies. So, we end up with flake8-4.0.1 and hacking-0.5.4 installed. And that doesn't work. Limiting the version of hacking to >=3.0 to have flake8-3.9.2 and hacking-3.0.0 installed during backtracking. Signed-off-by: Ilya Maximets Acked-by: Dumitru Ceara [i.maximets: 2 tags below carried from v1, that had no >=3.0 change] Acked-by: Gaetan Rivet Acked-by: Aaron Conole Signed-off-by: Numan Siddique (cherry picked from OVS commit d5453008c419512ba5a31dade5d394984b6161a1) (cherry picked from commit 889037e2905447a601fab8f78e6ece46c5d45773) Signed-off-by: Vladislav Odintsov --- .ci/linux-prepare.sh | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/.ci/linux-prepare.sh b/.ci/linux-prepare.sh index 37e8d4250..e0c528479 100755 --- a/.ci/linux-prepare.sh +++ b/.ci/linux-prepare.sh @@ -12,4 +12,10 @@ set -ev git clone git://git.kernel.org/pub/scm/devel/sparse/sparse.git cd sparse && make -j4 HAVE_LLVM= HAVE_SQLITE= install && cd .. -pip3 install --disable-pip-version-check --user flake8 hacking sphinx pyOpenSSL +# Installing wheel separately because it may be needed to build some +# of the packages during dependency backtracking and pip >= 22.0 will +# abort backtracking on build failures: +# https://github.com/pypa/pip/issues/10655 +pip3 install --disable-pip-version-check --user wheel +pip3 install --disable-pip-version-check --user \ +flake8 'hacking>=3.0' sphinx setuptools pyelftools pyOpenSSL -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn branch-20.06 3/3] ovn-ic: Only monitor useful tables and columns.
From: Dumitru Ceara Signed-off-by: Dumitru Ceara Signed-off-by: Mark Michelson Acked-by: Mark Michelson (cherry picked from commit 2698e7811b41b00ac3b6544430a95be9ae700e23) Signed-off-by: Vladislav Odintsov --- ic/ovn-ic.c | 106 +--- 1 file changed, 101 insertions(+), 5 deletions(-) diff --git a/ic/ovn-ic.c b/ic/ovn-ic.c index 0888344e2..788946ac8 100644 --- a/ic/ovn-ic.c +++ b/ic/ovn-ic.c @@ -1613,13 +1613,109 @@ main(int argc, char *argv[]) struct ovsdb_idl_loop ovnisb_idl_loop = OVSDB_IDL_LOOP_INITIALIZER( ovsdb_idl_create(ovn_ic_sb_db, &icsbrec_idl_class, true, true)); -/* ovn-nb db. XXX: add only needed tables and columns */ +/* ovn-nb db. */ struct ovsdb_idl_loop ovnnb_idl_loop = OVSDB_IDL_LOOP_INITIALIZER( -ovsdb_idl_create(ovnnb_db, &nbrec_idl_class, true, true)); - -/* ovn-sb db. XXX: add only needed tables and columns */ +ovsdb_idl_create(ovnnb_db, &nbrec_idl_class, false, true)); + +ovsdb_idl_add_table(ovnnb_idl_loop.idl, &nbrec_table_nb_global); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, &nbrec_nb_global_col_name); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, &nbrec_nb_global_col_options); + +ovsdb_idl_add_table(ovnnb_idl_loop.idl, +&nbrec_table_logical_router_static_route); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_static_route_col_ip_prefix); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_static_route_col_nexthop); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_static_route_col_external_ids); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_static_route_col_policy); + +ovsdb_idl_add_table(ovnnb_idl_loop.idl, &nbrec_table_logical_router); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_col_name); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_col_static_routes); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_col_ports); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_col_options); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_col_external_ids); + +ovsdb_idl_add_table(ovnnb_idl_loop.idl, &nbrec_table_logical_router_port); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_port_col_name); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_port_col_networks); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_port_col_external_ids); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_router_port_col_options); + +ovsdb_idl_add_table(ovnnb_idl_loop.idl, &nbrec_table_logical_switch); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_col_name); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_col_ports); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_col_other_config); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_col_external_ids); + +ovsdb_idl_add_table(ovnnb_idl_loop.idl, &nbrec_table_logical_switch_port); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_name); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_addresses); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_options); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_type); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_up); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_addresses); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_enabled); +ovsdb_idl_add_column(ovnnb_idl_loop.idl, + &nbrec_logical_switch_port_col_external_ids); + +/* ovn-sb db. */ struct ovsdb_idl_loop ovnsb_idl_loop = OVSDB_IDL_LOOP_INITIALIZER( -ovsdb_idl_create(ovnsb_db, &sbrec_idl_class, true, true)); +ovsdb_idl_create(ovnsb_db, &sbrec_idl_class, false, true)); + +ovsdb_idl_add_table(ovnsb_idl_loop.idl, &sbrec_table_chassis); +ovsdb_idl_add_column(ovnsb_idl_loop.i
[ovs-dev] [PATCH ovn branch-20.06 1/3] ci: Install wheel before installing any other python packages.
From: Ilya Maximets GHA is broken due to update to pip>=22.0. This happens because now it stops backtracking packages on build failure making it impossible to find working combination of versions. We're not able to build 'hacking', because 'wheel' is not installed at that point in time. Installing it separately to fix the issue, so pip can find compatible versions of packages by backtracking. Unfortunately, new version of backtracking leads to installation of incompatible versions of flake8 and hacking. Presumably because current versions of hacking are not compatible with flake8>=4.0 and very old hacking-0.5.4 for some reason is considered suitable while resolving dependencies. So, we end up with flake8-4.0.1 and hacking-0.5.4 installed. And that doesn't work. Limiting the version of hacking to >=3.0 to have flake8-3.9.2 and hacking-3.0.0 installed during backtracking. Signed-off-by: Ilya Maximets Acked-by: Dumitru Ceara [i.maximets: 2 tags below carried from v1, that had no >=3.0 change] Acked-by: Gaetan Rivet Acked-by: Aaron Conole Signed-off-by: Numan Siddique (cherry picked from OVS commit d5453008c419512ba5a31dade5d394984b6161a1) (cherry picked from commit 889037e2905447a601fab8f78e6ece46c5d45773) Signed-off-by: Vladislav Odintsov --- .ci/linux-prepare.sh | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/.ci/linux-prepare.sh b/.ci/linux-prepare.sh index 37e8d4250..e0c528479 100755 --- a/.ci/linux-prepare.sh +++ b/.ci/linux-prepare.sh @@ -12,4 +12,10 @@ set -ev git clone git://git.kernel.org/pub/scm/devel/sparse/sparse.git cd sparse && make -j4 HAVE_LLVM= HAVE_SQLITE= install && cd .. -pip3 install --disable-pip-version-check --user flake8 hacking sphinx pyOpenSSL +# Installing wheel separately because it may be needed to build some +# of the packages during dependency backtracking and pip >= 22.0 will +# abort backtracking on build failures: +# https://github.com/pypa/pip/issues/10655 +pip3 install --disable-pip-version-check --user wheel +pip3 install --disable-pip-version-check --user \ +flake8 'hacking>=3.0' sphinx setuptools pyelftools pyOpenSSL -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH ovn branch-20.06 2/3] Fix compilation issue in fedora 37/rawhide.
From: Numan Siddique Compilation is failing with the error: File "Documentation/conf.py", line 61, in with open(filename, 'rU') as f: ValueError: invalid mode: 'rU' The python 3 documentation [1] says: There is an additional mode character permitted, 'U', which no longer has any effect, and is considered deprecated. It previously enabled universal newlines in text mode, which became the default behaviour in Python 3.0. Refer to the documentation of the newline parameter for further details. [1] - https://docs.python.org/3.9/library/functions.html#open This patch fixes this issue. Acked-by: Dumitru Ceara Signed-off-by: Numan Siddique (cherry picked from commit 500982b84280fdc451877c76f5fdb9a0ac19e805) Signed-off-by: Vladislav Odintsov --- Documentation/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/conf.py b/Documentation/conf.py index d89c64e77..f7eceaec8 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -58,7 +58,7 @@ author = u'The Open Virtual Network (OVN) Development Community' # The full version, including alpha/beta/rc tags. release = None filename = "../configure.ac" -with open(filename, 'rU') as f: +with open(filename, 'r') as f: for line in f: if 'AC_INIT' in line: # Parse "AC_INIT(openvswitch, 2.7.90, b...@openvswitch.org)": -- 2.36.1 ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
