ovn-northd is the only writer of the Southbound DNS table:
sync_dns_entries() rewrites the records and datapaths columns from the
Northbound contents on every recompute.  The write-back of ovn-northd's
own transaction therefore alerts the IDL for no reason, and because
en_sb_dns has no change handler registered, every such alert forces a
full recompute of the en_northd node.

Disable IDL alerting for all SB DNS columns, as we already do for the
other tables ovn-northd owns.  The rows stay replicated, so
sync_dns_entries() can still read them; only the change notification is
suppressed.

Add a test that writes to the SB DNS table directly and checks that the
northd engine node neither recomputes nor computes, and that a
subsequent recompute restores the records column from the Northbound
contents.

Signed-off-by: Lana Honcharuk <[email protected]>
Assisted-by: Claude Opus 4.6
---
v2: Replaced the en_sb_dns noop handler with ovsdb_idl_omit_alert() on all
    SB DNS columns, as suggested by Dumitru.  Reworked the test: with
    alerting disabled ovn-northd is not woken at all, so the northd node
    is now expected to be "norecompute nocompute" rather than
    "norecompute compute".  Fixed the checkpatch whitespace error and the
    unbracketed [1-9] in the test's m4.

 northd/ovn-northd.c |  3 +++
 tests/ovn-northd.at | 47 +++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+)

diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
index 499cf9edd..b7bf310c2 100644
--- a/northd/ovn-northd.c
+++ b/northd/ovn-northd.c
@@ -989,6 +989,9 @@ main(int argc, char *argv[])
         ovsdb_idl_omit_alert(ovnsb_idl_loop.idl,
                              &sbrec_advertised_mac_binding_columns[i]);
     }
+    for (size_t i = 0; i < SBREC_DNS_N_COLUMNS; i++) {
+        ovsdb_idl_omit_alert(ovnsb_idl_loop.idl, &sbrec_dns_columns[i]);
+    }
 
     unixctl_command_register("sb-connection-status", "", 0, 0,
                              ovn_conn_show, ovnsb_idl_loop.idl);
diff --git a/tests/ovn-northd.at b/tests/ovn-northd.at
index 6d191c1a0..c8a7aeefb 100644
--- a/tests/ovn-northd.at
+++ b/tests/ovn-northd.at
@@ -12164,6 +12164,53 @@ ignored_dp=lr0])
 AT_CLEANUP
 ])
 
+OVN_FOR_EACH_NORTHD_NO_HV([
+AT_SETUP([SB DNS incremental processing])
+ovn_start
+
+check ovn-nbctl ls-add sw0
+dns_uuid=$(ovn-nbctl create DNS records={})
+check ovn-nbctl set DNS $dns_uuid records:vm1.ovn.org="10.0.0.4"
+check ovn-nbctl set Logical_Switch sw0 dns_records="$dns_uuid"
+check ovn-nbctl --wait=sb sync
+
+# ovn-northd syncs the NB DNS record to the SB DNS table.
+wait_row_count sb:DNS 1
+sb_dns_uuid=$(fetch_column sb:DNS _uuid)
+AT_CHECK([ovn-sbctl get DNS $sb_dns_uuid records:vm1.ovn.org], [0], [dnl
+"10.0.0.4"
+])
+
+# ovn-northd is the only writer of the SB DNS table and disables IDL
+# alerting for all of its columns, so changes to that table never wake
+# ovn-northd up - not even the write-back of its own transaction.  A direct
+# SB write is therefore not noticed at all: the northd node neither
+# recomputes nor computes.
+check as northd ovn-appctl -t ovn-northd inc-engine/clear-stats
+check ovn-sbctl set DNS $sb_dns_uuid records:vm2.ovn.org="10.0.0.5"
+check ovn-nbctl --wait=sb sync
+check_engine_stats northd norecompute nocompute
+check_engine_stats lflow norecompute nocompute
+
+# The externally added record is consequently still there.
+AT_CHECK([ovn-sbctl get DNS $sb_dns_uuid records:vm2.ovn.org], [0], [dnl
+"10.0.0.5"
+])
+
+# sync_dns_entries() rewrites the records column from the NB contents, so a
+# recompute drops the stale entry without changing anything else.
+CHECK_NO_CHANGE_AFTER_RECOMPUTE
+wait_row_count sb:DNS 0 records:vm2.ovn.org='"10.0.0.5"'
+wait_row_count sb:DNS 1 records:vm1.ovn.org='"10.0.0.4"'
+
+# Dropping the NB record removes the SB one as well.
+check ovn-nbctl clear Logical_Switch sw0 dns_records
+check ovn-nbctl --wait=sb sync
+wait_row_count sb:DNS 0
+
+AT_CLEANUP
+])
+
 OVN_FOR_EACH_NORTHD_NO_HV([
 AT_SETUP([ACL/Meter incremental processing - no northd recompute])
 ovn_start
-- 
2.39.5 (Apple Git-154)

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to