| Message ID | 20210218011221.1354839-6-blp@ovn.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add DDlog implementation of ovn-northd | expand |
diff --git a/ovn-sb.ovsschema b/ovn-sb.ovsschema index 0d20f0826646..07eb54b10dd4 100644 --- a/ovn-sb.ovsschema +++ b/ovn-sb.ovsschema @@ -1,7 +1,7 @@ { "name": "OVN_Southbound", - "version": "20.15.0", - "cksum": "539683023 25965", + "version": "20.16.0", + "cksum": "3127541865 25965", "tables": { "SB_Global": { "columns": { @@ -133,7 +133,7 @@ "ports": {"type": {"key": {"type": "uuid", "refTable": "Port_Binding", "refType": "weak"}, - "min": 1, "max": "unlimited"}}}, + "min": 0, "max": "unlimited"}}}, "indexes": [["datapath", "tunnel_key"], ["datapath", "name"]], "isRoot": true},
I don't know a good reason to intentionally create an empty multicast group, but disallowing empty multicast groups has an odd side effect: you can delete all but one of the ports that a group contains and the database will happily remove the ports from the group automatically (because 'ports' is a set of weak references) but if you try to delete the last port that the group contained, the database server will reject the whole transaction. That's really weird. By allowing a multicast group with no ports, we avoid this special case. Signed-off-by: Ben Pfaff <blp@ovn.org> --- ovn-sb.ovsschema | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)