On 8/13/25 7:20 PM, Mark Michelson via dev wrote:
> Prior to this commit, if you wanted to find the corresponding northbound
> UUID for a southbound Logical Datapath, you could find it in one of two
> places:
>
> For logical switches, it was in external-ids:logical-switch.
> For logical routers, it was in external-ids:logical-router.
>
> With this commit, we are separating the type and UUID into separate
> fields. This way, no matter the type of the datapath, you can find the
> UUID. And you can find the type of the datapath without having to
> potentially check multiple external-ids keys to do so.
>
> These fields are going to be used pretty heavily by northd in upcoming
> patches, so instead of making them external-ids, these are now
> full-fledged columns on the southbound Datapath_Binding. The UUID of the
> northbound logical datapath is in a column called "nb_uuid" and the type
> of the logical datapath is stored in an enumerated column called "type".
>
> Note that there is a seemingly-unrelated change in the check packet
> length test in tests/ovn.at. This test started failing because its use
> of `grep` was picking up the new "nb_uuid" column accidentally. The
> change to the test uses `fetch_column` since it is more precise.
>
> Signed-off-by: Mark Michelson <[email protected]>
> Acked-by: Ales Musil <[email protected]>
> ---
> V17:
> - cherry picked from v15
> ---
> controller/local_data.c | 2 +-
> ic/ovn-ic.c | 5 +++--
> lib/ovn-util.c | 45 +++++++++++++++++++++++++++++++++++++++++
> lib/ovn-util.h | 8 ++++++++
> northd/northd.c | 38 +++++++++++++++++-----------------
> northd/northd.h | 5 +++--
> ovn-sb.ovsschema | 11 ++++++++--
> ovn-sb.xml | 21 ++++++++++---------
> tests/ovn-controller.at | 4 ++++
> tests/ovn-northd.at | 6 +++---
> tests/ovn.at | 6 ++----
> utilities/ovn-sbctl.c | 4 ++--
> utilities/ovn-trace.c | 3 +--
> 13 files changed, 112 insertions(+), 46 deletions(-)
<snip>
> /* Returns an "enum ovn_stage" built from the arguments.
> diff --git a/ovn-sb.ovsschema b/ovn-sb.ovsschema
> index 4c24f5b51..8bc7bbba3 100644
> --- a/ovn-sb.ovsschema
> +++ b/ovn-sb.ovsschema
> @@ -1,7 +1,7 @@
> {
> "name": "OVN_Southbound",
> - "version": "21.2.0",
> - "cksum": "29145795 34859",
> + "version": "21.3.0",
> + "cksum": "3179330761 35286",
> "tables": {
> "SB_Global": {
> "columns": {
> @@ -196,6 +196,13 @@
> "load_balancers": {"type": {"key": {"type": "uuid"},
> "min": 0,
> "max": "unlimited"}},
> + "type": {"type": {"key": {"type": "string",
> + "enum": ["set",
> + ["logical-switch",
> + "logical-router"]]}}},
Hi, Mark, Dumitru, Ales.
This change breaks upgrades, at least in active-backup database configuration.
When the old database is converted to the new schema, the default value for
the column is an empty string. But this is against the schema definition.
This is not a problem for the database itself, as it doesn't check these
constraints, but if we have the backup database connected, it will check the
constraints upon receiving the new data and will fail:
|replication|INFO|OVN_Southbound: Monitor reply received. Resetting the
database.
|00045|ovsdb_error|ERR|unexpected ovsdb error: constraint violation: "" is not
one of the allowed values ([logical-router,
logical-switch])
At this point the backup server will disconnect and turn into active server
as ti thinks that the origin is broken. We probably need to allow this
column to not have a value specified.
It's fairly easy to reporoduce - get an older database and start a sandbox
with it. The sb2 will error out and disconnect.
Also, northd and ovn-controller should be able to handle this case where
the column is not yet set after upgrade. I didn't check if that works or
not.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
