ovn: Rename "ovn" database to "ovn-sb".

It was confusing having a database called "ovn", since it's also the
name of the project.  Since we have an "ovn-nb", rename "ovn" to
"ovn-sb".

Signed-off-by: Justin Pettit <jpettit@nicira.com>

ovn/.gitignore

@@ -1,17 +1,17 @@
-/ovn.5
-/ovn.gv
-/ovn.pic
 /ovn-architecture.7
 /ovn-controller.8
-/ovn-idl.c
-/ovn-idl.h
-/ovn-idl.ovsidl
 /ovn-nb.5
 /ovn-nb.gv
 /ovn-nb.pic
 /ovn-nb-idl.c
 /ovn-nb-idl.h
 /ovn-nb-idl.ovsidl
+/ovn-sb.5
+/ovn-sb.gv
+/ovn-sb.pic
+/ovn-sb-idl.c
+/ovn-sb-idl.h
+/ovn-sb-idl.ovsidl
 /ovn-nbctl
 /ovn-nbctl.8
 /ovn-nbd

ovn/TODO

@@ -159,7 +159,7 @@
 
     We can probably use the same default as ovs-vsctl.
 
-*** Location of OVN database.
+*** Location of OVN Southbound database.
 
     Probably no useful default.
 
@@ -183,16 +183,16 @@
    Initially, the simplest way to do this is probably to write
    straight C code to do a full translation of the entire
    OVN_Northbound database into the format for the Pipeline table in
-   the OVN database.  As scale increases, this will probably be too
-   inefficient since a small change in OVN_Northbound requires a full
-   recomputation.  At that point, we probably want to adopt a more
-   systematic approach, such as something akin to the "nlog" system
-   used in NVP (see Koponen et al. "Network Virtualization in
-   Multi-tenant Datacenters", NSDI 2014).
+   the OVN Southbound database.  As scale increases, this will probably
+   be too inefficient since a small change in OVN_Northbound requires a
+   full recomputation.  At that point, we probably want to adopt a more
+   systematic approach, such as something akin to the "nlog" system used
+   in NVP (see Koponen et al. "Network Virtualization in Multi-tenant
+   Datacenters", NSDI 2014).
 
 ** Push logical datapath flows to Pipeline table.
 
-** Monitor OVN database Bindings table.
+** Monitor OVN Southbound database Bindings table.
 
    Sync rows in the OVN Bindings table to the "up" column in the
    OVN_Northbound database.
@@ -208,9 +208,9 @@
 ** Scaling number of connections.
 
    In typical use today a given ovsdb-server has only a single-digit
-   number of simultaneous connections.  The OVN database will have a
-   connection from every hypervisor.  This use case needs testing and
-   probably coding work.  Here are some possible improvements.
+   number of simultaneous connections.  The OVN Southbound database will
+   have a connection from every hypervisor.  This use case needs testing
+   and probably coding work.  Here are some possible improvements.
 
 *** Reducing amount of data sent to clients.
 

ovn/automake.mk

@@ -1,35 +1,35 @@
-# OVN schema and IDL
-EXTRA_DIST += ovn/ovn.ovsschema
-pkgdata_DATA += ovn/ovn.ovsschema
+# OVN southbound schema and IDL
+EXTRA_DIST += ovn/ovn-sb.ovsschema
+pkgdata_DATA += ovn/ovn-sb.ovsschema
 
-# OVN E-R diagram
+# OVN southbound E-R diagram
 #
 # If "python" or "dot" is not available, then we do not add graphical diagram
 # to the documentation.
 if HAVE_PYTHON
 if HAVE_DOT
-ovn/ovn.gv: ovsdb/ovsdb-dot.in ovn/ovn.ovsschema
-	$(AM_V_GEN)$(OVSDB_DOT) --no-arrows $(srcdir)/ovn/ovn.ovsschema > $@
-ovn/ovn.pic: ovn/ovn.gv ovsdb/dot2pic
-	$(AM_V_GEN)(dot -T plain < ovn/ovn.gv | $(PERL) $(srcdir)/ovsdb/dot2pic -f 3) > $@.tmp && \
+ovn/ovn-sb.gv: ovsdb/ovsdb-dot.in ovn/ovn-sb.ovsschema
+	$(AM_V_GEN)$(OVSDB_DOT) --no-arrows $(srcdir)/ovn/ovn-sb.ovsschema > $@
+ovn/ovn-sb.pic: ovn/ovn-sb.gv ovsdb/dot2pic
+	$(AM_V_GEN)(dot -T plain < ovn/ovn-sb.gv | $(PERL) $(srcdir)/ovsdb/dot2pic -f 3) > $@.tmp && \
 	mv $@.tmp $@
-OVN_PIC = ovn/ovn.pic
-OVN_DOT_DIAGRAM_ARG = --er-diagram=$(OVN_PIC)
-DISTCLEANFILES += ovn/ovn.gv ovn/ovn.pic
+OVN_SB_PIC = ovn/ovn-sb.pic
+OVN_SB_DOT_DIAGRAM_ARG = --er-diagram=$(OVN_SB_PIC)
+DISTCLEANFILES += ovn/ovn-sb.gv ovn/ovn-sb.pic
 endif
 endif
 
-# OVN schema documentation
-EXTRA_DIST += ovn/ovn.xml
-DISTCLEANFILES += ovn/ovn.5
-man_MANS += ovn/ovn.5
-ovn/ovn.5: \
-	ovsdb/ovsdb-doc ovn/ovn.xml ovn/ovn.ovsschema $(OVN_PIC)
+# OVN southbound schema documentation
+EXTRA_DIST += ovn/ovn-sb.xml
+DISTCLEANFILES += ovn/ovn-sb.5
+man_MANS += ovn/ovn-sb.5
+ovn/ovn-sb.5: \
+	ovsdb/ovsdb-doc ovn/ovn-sb.xml ovn/ovn-sb.ovsschema $(OVN_SB_PIC)
 	$(AM_V_GEN)$(OVSDB_DOC) \
-		$(OVN_DOT_DIAGRAM_ARG) \
+		$(OVN_SB_DOT_DIAGRAM_ARG) \
 		--version=$(VERSION) \
-		$(srcdir)/ovn/ovn.ovsschema \
-		$(srcdir)/ovn/ovn.xml > $@.tmp && \
+		$(srcdir)/ovn/ovn-sb.ovsschema \
+		$(srcdir)/ovn/ovn-sb.xml > $@.tmp && \
 	mv $@.tmp $@
 
 # OVN northbound schema and IDL
@@ -78,19 +78,19 @@ EXTRA_DIST += \
 	ovn/TODO \
 	ovn/CONTAINERS.OpenStack.md
 
-# ovn IDL
+# ovn-sb IDL
 OVSIDL_BUILT += \
-	$(srcdir)/ovn/ovn-idl.c \
-	$(srcdir)/ovn/ovn-idl.h \
-	$(srcdir)/ovn/ovn.ovsidl
-EXTRA_DIST += $(srcdir)/ovn/ovn-idl.ann
-OVN_IDL_FILES = \
-	$(srcdir)/ovn/ovn.ovsschema \
-	$(srcdir)/ovn/ovn-idl.ann
-$(srcdir)/ovn/ovn-idl.ovsidl: $(OVN_IDL_FILES)
-	$(AM_V_GEN)$(OVSDB_IDLC) annotate $(OVN_IDL_FILES) > $@.tmp && \
+	$(srcdir)/ovn/ovn-sb-idl.c \
+	$(srcdir)/ovn/ovn-sb-idl.h \
+	$(srcdir)/ovn/ovn-sb.ovsidl
+EXTRA_DIST += $(srcdir)/ovn/ovn-sb-idl.ann
+OVN_SB_IDL_FILES = \
+	$(srcdir)/ovn/ovn-sb.ovsschema \
+	$(srcdir)/ovn/ovn-sb-idl.ann
+$(srcdir)/ovn/ovn-sb-idl.ovsidl: $(OVN_SB_IDL_FILES)
+	$(AM_V_GEN)$(OVSDB_IDLC) annotate $(OVN_SB_IDL_FILES) > $@.tmp && \
 	mv $@.tmp $@
-CLEANFILES += ovn/ovn-idl.c ovn/ovn-idl.h
+CLEANFILES += ovn/ovn-sb-idl.c ovn/ovn-sb-idl.h
 
 # ovn-nb IDL
 OVSIDL_BUILT += \
@@ -113,8 +113,8 @@ ovn_libovn_la_LDFLAGS = \
         -Wl,--version-script=$(top_builddir)/ovn/libovn.sym \
         $(AM_LDFLAGS)
 ovn_libovn_la_SOURCES = \
-	ovn/ovn-idl.c \
-	ovn/ovn-idl.h \
+	ovn/ovn-sb-idl.c \
+	ovn/ovn-sb-idl.h \
 	ovn/ovn-nb-idl.c \
 	ovn/ovn-nb-idl.h
 

ovn/ovn-architecture.7.xml

@@ -109,21 +109,21 @@
 
     <li>
       <code>ovn-nbd</code>(8) connects to the OVN Northbound Database above it
-      and the OVN Database below it.  It translates the logical network
-      configuration in terms of conventional network concepts, taken from the
-      OVN Northbound Database, into logical datapath flows in the OVN Database
-      below it.
+      and the OVN Southbound Database below it.  It translates the
+      logical network configuration in terms of conventional network
+      concepts, taken from the OVN Northbound Database, into logical
+      datapath flows in the OVN Southbound Database below it.
     </li>
 
     <li>
       <p>
-	The <dfn>OVN Database</dfn> is the center of the system.  Its clients
-	are <code>ovn-nbd</code>(8) above it and <code>ovn-controller</code>(8)
-	on every transport node below it.
+    The <dfn>OVN Southbound Database</dfn> is the center of the system.
+    Its clients are <code>ovn-nbd</code>(8) above it and
+    <code>ovn-controller</code>(8) on every transport node below it.
       </p>
 
       <p>
-	The OVN Database contains three kinds of data: <dfn>Physical
+	The OVN Southbound Database contains three kinds of data: <dfn>Physical
 	Network</dfn> (PN) tables that specify how to reach hypervisor and
 	other nodes, <dfn>Logical Network</dfn> (LN) tables that describe the
 	logical network in terms of ``logical datapath flows,'' and
@@ -134,9 +134,10 @@
       </p>
 
       <p>
-	OVN Database performance must scale with the number of transport nodes.
-	This will likely require some work on <code>ovsdb-server</code>(1) as
-	we encounter bottlenecks.  Clustering for availability may be needed.
+    OVN Southbound Database performance must scale with the number of
+    transport nodes.  This will likely require some work on
+    <code>ovsdb-server</code>(1) as we encounter bottlenecks.
+    Clustering for availability may be needed.
       </p>
     </li>
   </ul>
@@ -148,13 +149,14 @@
   <ul>
     <li>
       <code>ovn-controller</code>(8) is OVN's agent on each hypervisor and
-      software gateway.  Northbound, it connects to the OVN Database to learn
-      about OVN configuration and status and to populate the PN table and the
-      <code>Chassis</code> column in <code>Bindings</code> table with the
-      hypervisor's status.  Southbound, it connects to
-      <code>ovs-vswitchd</code>(8) as an OpenFlow controller, for control over
-      network traffic, and to the local <code>ovsdb-server</code>(1) to allow
-      it to monitor and control Open vSwitch configuration.
+      software gateway.  Northbound, it connects to the OVN Southbound
+      Database to learn about OVN configuration and status and to
+      populate the PN table and the <code>Chassis</code> column in
+      <code>Bindings</code> table with the hypervisor's status.
+      Southbound, it connects to <code>ovs-vswitchd</code>(8) as an
+      OpenFlow controller, for control over network traffic, and to the
+      local <code>ovsdb-server</code>(1) to allow it to monitor and
+      control Open vSwitch configuration.
     </li>
 
     <li>
@@ -180,14 +182,14 @@
                        +-----------|-----------+
                                    |
                                    |
-                                +------+
-                                |OVN DB|
-                                +------+
+                         +-------------------+
+                         | OVN Southbound DB |
+                         +-------------------+
                                    |
                                    |
                 +------------------+------------------+
                 |                  |                  |
- HV 1           |                  |    HV n          |
+  HV 1          |                  |    HV n          |
 +---------------|---------------+  .  +---------------|---------------+
 |               |               |  .  |               |               |
 |        ovn-controller         |  .  |        ovn-controller         |
@@ -267,7 +269,7 @@
 
   <p>
     The steps in this example refer often to details of the OVN and OVN
-    Northbound database schemas.  Please see <code>ovn</code>(5) and
+    Northbound database schemas.  Please see <code>ovn-sb</code>(5) and
     <code>ovn-nb</code>(5), respectively, for the full story on these
     databases.
   </p>
@@ -290,14 +292,15 @@
     </li>
 
     <li>
-      <code>ovn-nbd</code> receives the OVN Northbound database update.  In
-      turn, it makes the corresponding updates to the OVN database, by adding
-      rows to the OVN database <code>Pipeline</code> table to reflect the new
-      port, e.g. add a flow to recognize that packets destined to the new
-      port's MAC address should be delivered to it, and update the flow that
-      delivers broadcast and multicast packets to include the new port.  It
-      also creates a record in the <code>Bindings</code> table and populates
-      all its columns except the column that identifies the
+      <code>ovn-nbd</code> receives the OVN Northbound database update.
+      In turn, it makes the corresponding updates to the OVN Southbound
+      database, by adding rows to the OVN Southbound database
+      <code>Pipeline</code> table to reflect the new port, e.g. add a
+      flow to recognize that packets destined to the new port's MAC
+      address should be delivered to it, and update the flow that
+      delivers broadcast and multicast packets to include the new port.
+      It also creates a record in the <code>Bindings</code> table and
+      populates all its columns except the column that identifies the
       <code>chassis</code>.
     </li>
 
@@ -386,9 +389,10 @@
 
     <li>
       <code>ovn-nbd</code> receives the OVN Northbound update and in turn
-      updates the OVN database accordingly, by removing or updating the
-      rows from the OVN database <code>Pipeline</code> table and
-      <code>Bindings</code> table that were related to the now-destroyed VIF.
+      updates the OVN Southbound database accordingly, by removing or
+      updating the rows from the OVN Southbound database
+      <code>Pipeline</code> table and <code>Bindings</code> table that
+      were related to the now-destroyed VIF.
     </li>
 
     <li>
@@ -482,10 +486,11 @@
 
     <li>
       <code>ovn-nbd</code> receives the OVN Northbound database update.  In
-      turn, it makes the corresponding updates to the OVN database, by adding
-      rows to the OVN database's <code>Pipeline</code> table to reflect the new
-      port and also by creating a new row in the <code>Bindings</code> table
-      and populating all its columns except the column that identifies the
+      turn, it makes the corresponding updates to the OVN Southbound
+      database, by adding rows to the OVN Southbound database's
+      <code>Pipeline</code> table to reflect the new port and also by
+      creating a new row in the <code>Bindings</code> table and
+      populating all its columns except the column that identifies the
       <code>chassis</code>.
     </li>
 
@@ -521,10 +526,11 @@
 
     <li>
       <code>ovn-nbd</code> receives the OVN Northbound update and in turn
-      updates the OVN database accordingly, by removing or updating the
-      rows from the OVN database <code>Pipeline</code> table that were related
-      to the now-destroyed CIF.  It also deletes the row in the
-      <code>Bindings</code> table for that CIF.
+      updates the OVN Southbound database accordingly, by removing or
+      updating the rows from the OVN Southbound database
+      <code>Pipeline</code> table that were related to the now-destroyed
+      CIF.  It also deletes the row in the <code>Bindings</code> table
+      for that CIF.
     </li>
 
     <li>

ovn/ovn-controller.8.in

@@ -15,8 +15,8 @@ ovn\-controller \- OVN local controller
 .
 .SH DESCRIPTION
 \fBovn\-controller\fR is the local controller daemon for OVN, the Open
-Virtual Network.  It connects northbound to the OVN database (see
-\fBovn\fR(5)) over the OVSDB protocol, and southbound to the Open
+Virtual Network.  It connects up to the OVN Southbound database (see
+\fBovn\-sb\fR(5)) over the OVSDB protocol, and down to the Open
 vSwitch database (see \fBovs-vswitchd.conf.db\fR(5)) over the OVSDB
 protocol and to \fBovs\-vswitchd\fR(8) via OpenFlow.  Each hypervisor
 and software gateway in an OVN deployment runs its own independent