[ovs-dev] [PATCH v1 4/4] ovn: document l3ha redirect-chassis changes

[majopela at redhat.com]

From: Miguel Angel Ajo <majopela at redhat.com>

This commit documents the ovn-architecture, ovn-nb
and ovn-sb changes to the redirect-chassis option
in Logical_Router_Port and Port_Binding tables.

Signed-off-by: Miguel Angel Ajo <majopela at redhat.com>
---
 ovn/ovn-architecture.7.xml |  6 ++++--
 ovn/ovn-nb.xml             | 25 +++++++++++++++++--------
 ovn/ovn-sb.xml             | 13 ++++++++++---
 3 files changed, 31 insertions(+), 13 deletions(-)

diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml
index bce32a6..3c4b8a9 100644
--- a/ovn/ovn-architecture.7.xml
+++ b/ovn/ovn-architecture.7.xml
@@ -1331,8 +1331,10 @@
     simply a way to indicate that although the packet is destined for
     the distributed gateway port, it needs to be redirected to a
     different chassis.  At table 32, packets with this logical egress
-    port are sent to a specific chassis, in the same way that table 32
-    directs packets whose logical egress port is a VIF or a type
+    port are sent to a specific chassis, or to the master chassis from
+    a set of chassis defined in the <code>redirect-chassis</code> option,
+    in the same way that table 32 directs packets whose logical egress
+    port is a VIF or a type
     <code>l3gateway</code> port to different chassis.  Once the packet
     arrives at that chassis, table 33 resets the logical egress port to
     the value representing the distributed gateway port.  For each
diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
index eb348fe..8c133fb 100644
--- a/ovn/ovn-nb.xml
+++ b/ovn/ovn-nb.xml
@@ -1281,13 +1281,13 @@
         </p>
 
         <p>
-          Even when a <code>redirect-chassis</code> is specified, the
+          Even when <code>redirect-chassis</code> is specified, the
           logical router port still effectively resides on each chassis.
           However, due to the implications of the use of L2 learning in the
           physical network, as well as the need to support advanced features
           such as one-to-many NAT (aka IP masquerading), a subset of the
           logical router processing is handled in a centralized manner on
-          the specified <code>redirect-chassis</code>.
+          the specified set of <code>redirect-chassis</code>.
         </p>
 
         <p>
@@ -1297,10 +1297,18 @@
           column="external_mac" table="NAT"/>s specified in NAT rules are
           automatically programmed in the peer logical switch's
           destination lookup on the chassis where the <ref
-          column="logical_port" table="NAT"/> resides.  In addition, the
-          logical router's MAC address is automatically programmed in the
-          peer logical switch's destination lookup flow on the
-          <code>redirect-chassis</code>.
+              column="logical_port" table="NAT"/> resides and is master.
+          In addition, the logical router's MAC address is automatically
+          programmed in the peer logical switch's destination lookup flow
+          on the <code>redirect-chassis</code>.
+        </p>
+        <p>
+          The following format is accepted:
+          <code><var>chassis1_name</var>[:<var>chassis1_prio</var>]</code>
+          <code>[,<var>chassis2_name</var>[:<var>chassis2_prio</var>]]</code>
+          <code>[...]</code>
+          where priorities are in decimal values, and an higher numbers means
+          higher priority.
         </p>
 
         <p>
@@ -1462,7 +1470,8 @@
         processed in a distributed manner on all chassis.  If this is
         not specified for a NAT rule on a distributed router, then
         this NAT rule will be processed in a centralized manner on
-        the gateway port instance on the <code>redirect-chassis</code>.
+        the gateway port instance on the master
+        <code>redirect-chassis</code>.
       </p>
 
       <p>
@@ -1489,7 +1498,7 @@
         distributed manner on all chassis.  If this is not specified
         for a NAT rule on a distributed router, then this NAT rule
         will be processed in a centralized manner on the gateway
-        port instance on the <code>redirect-chassis</code>.
+        port instance on the master <code>redirect-chassis</code>.
       </p>
     </column>
   </table>
diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml
index f3c3212..b65e81b 100644
--- a/ovn/ovn-sb.xml
+++ b/ovn/ovn-sb.xml
@@ -1918,7 +1918,7 @@ tcp.flags = RST;
           <dt><code>chassisredirect</code></dt>
           <dd>
             A logical port that represents a particular instance, bound
-            to a specific chassis, of an otherwise distributed parent
+            to a specific set chassis, of an otherwise distributed parent
             port (e.g. of type <code>patch</code>).  A
             <code>chassisredirect</code> port should never be used as an
             <code>inport</code>.  When an ingress pipeline sets the
@@ -2122,8 +2122,15 @@ tcp.flags = RST;
       </column>
 
       <column name="options" key="redirect-chassis">
-        The <code>chassis</code> that this <code>chassisredirect</code> port
-        is bound to.  This is taken from <ref table="Logical_Router_Port"
+        The list of <code>chassis</code>, with optional priority that
+        this <code>chassisredirect</code> port is bound to. With the
+        following format:
+          <code><var>chassis1_name</var>[:<var>chassis1_prio</var>]</code>
+          <code>[,<var>chassis2_name</var>[:<var>chassis2_prio</var>]]</code>
+          <code>[...]</code>
+        where priorities are in decimal values, and an higher numbers means
+        higher priority.
+        This is taken from <ref table="Logical_Router_Port"
         column="options" key="redirect-chassis" db="OVN_Northbound"/>
         in the OVN_Northbound database's <ref table="Logical_Router_Port"
         db="OVN_Northbound"/> table.
-- 
1.8.3.1