ovn-sb.ovsschema: Avoid duplicated IPs in Encap table.

When adding a new chassis, if there is an old chassis with same IP existed in Encap table, it is allowed to be added today. However, allowing it to be added results in problems: 1. The new chassis cannot work because none of the other chassises are able to create tunnel to it, because of the IP confliction with already existed tunnel to the old chassis. 2. All the other chassises will continuously retry creating the tunnel and complaining about the error. So, instead of hiding the problem, it is better to expose it while trying to add the second chassis with duplicated IP. This patch ensures it from the ovsdb schema. Signed-off-by: Han Zhou <[email protected]> Signed-off-by: Ben Pfaff <[email protected]>
jotak · Dec 27, 2018 · b6413ae · b6413ae
1 parent eca4cde
commit b6413ae
Show file tree

Hide file tree

Showing 3 changed files with 37 additions and 3 deletions.
diff --git a/Documentation/intro/install/ovn-upgrades.rst b/Documentation/intro/install/ovn-upgrades.rst
@@ -75,6 +75,34 @@ or if you're using a Linux distribution with systemd::
 
     $ sudo systemctl restart ovn-northd
 
+Schema Change
+^^^^^^^^^^^^^
+
+During database upgrading, if there is schema change, the DB file will be
+converted to the new schema automatically, if the schema change is backward
+compatible.  OVN tries the best to keep the DB schemas backward compatible.
+
+However, there can be situations that an incompatible change is reasonble.  An
+example of such case is to add constraints in the table to ensure correctness.
+If there were already data that violates the new constraints got added somehow,
+it will result in DB upgrade failures.  In this case, user should manually
+correct data using ovn-nbctl (for north-bound DB) or ovn-sbctl (for south-
+bound DB), and then upgrade again following previous steps.  Below is a list
+of known impactible schema changes and how to fix when error encountered.
+
+#. Release 2.11: index [type, ip] added for Encap table of south-bound DB to
+   prevent duplicated IPs being used for same tunnel type.  If there are
+   duplicated data added already (e.g. due to improper chassis management),
+   a convenient way to fix is to find the chassis that is using the IP
+   with command::
+
+    $ ovn-sbctl show
+
+   Then delete the chassis with command::
+
+    $ ovn-sbctl chassis-del <chassis>
+
+
 Upgrading OVN Integration
 -------------------------
 

diff --git a/NEWS b/NEWS
@@ -7,6 +7,11 @@ Post-v2.10.0
    - The environment variable OVS_CTL_TIMEOUT, if set, is now used
      as the default timeout for control utilities.
    - ovn:
+     * OVN-SB schema changed: duplicated IP with same Encapsulation type
+       is not allowed any more.  Please refer to
+       Documentation/intro/install/ovn-upgrades.rst for the instructions
+       in case there are problems encountered when upgrading from an earlier
+       version.
      * New support for IPSEC encrypted tunnels between hypervisors.
      * ovn-ctl: allow passing user:group ids to the OVN daemons.
    - DPDK:

diff --git a/ovn/ovn-sb.ovsschema b/ovn/ovn-sb.ovsschema
@@ -1,7 +1,7 @@
 {
     "name": "OVN_Southbound",
-    "version": "1.17.0",
-    "cksum": "3217981733 15045",
+    "version": "2.0.0",
+    "cksum": "3109267860 15085",
     "tables": {
         "SB_Global": {
             "columns": {
@@ -50,7 +50,8 @@
                                      "min": 0,
                                      "max": "unlimited"}},
                 "ip": {"type": "string"},
-                "chassis_name": {"type": "string"}}},
+                "chassis_name": {"type": "string"}},
+            "indexes": [["type", "ip"]]},
         "Address_Set": {
             "columns": {
                 "name": {"type": "string"},