Until now, ovs-ctl has started ovsdb-server with the full set of remote
managers configured.  This means that ovsdb-server immediately connects to
these managers, before ovs-vswitchd even starts.  Because the Open vSwitch
schema has several ephemeral columns, there will be considerable startup
churn in the database.   For example, ovs-vswitchd will initially fill in
the datapath-id and ofport columns as it starts and sets up the initial
configuration.  This churn wastes bandwidth to the remote managers and has
potential for confusing them.

This commit reduces the churn by changing ovs-ctl so that ovsdb-server
connects to the remote managers only after ovs-vswitchd has finished its
initial configuration.  This means that remote managers will initially
see a filled-in database, not one that has its ephemeral columns empty.

This commit does not mean that managers can ignore the possibility that
some columns have not yet been filled in.  For example, some columns will
still be briefly blank after a new bridge or a new port is added at
runtime, because adding a bridge or port occurs in one transaction (made by
the client adding the port, e.g. ovs-vsctl) and filling in those columns
happens in a different transaction (made by ovs-vswitchd).  But this commit
does reduce the quantity of empty columns that I would expect a database
client to observe in practice.

Reported-by: Jeff Merrick <jmerr...@vmware.com>
CC: Amar Padmanabhan <a...@nicira.com>
Signed-off-by: Ben Pfaff <b...@nicira.com>
Bug #15983.
---
 AUTHORS              |    1 +
 utilities/ovs-ctl.in |   12 +++++++++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/AUTHORS b/AUTHORS
index 68bcf01..07dce20 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -101,6 +101,7 @@ Alan Shieh              ash...@nicira.com
 Alban Browaeys          pra...@yahoo.com
 Alex Yip                a...@nicira.com
 Alexey I. Froloff       ra...@altlinux.org
+Amar Padmanabhan        a...@nicira.com
 Amey Bhide              abh...@nicira.com
 André Ruß               andre.r...@hybris.com
 Andreas Beckmann        deb...@abeckmann.de
diff --git a/utilities/ovs-ctl.in b/utilities/ovs-ctl.in
index 5ad5f26..933c5d7 100755
--- a/utilities/ovs-ctl.in
+++ b/utilities/ovs-ctl.in
@@ -188,7 +188,6 @@ start_ovsdb () {
         done
         set "$@" -vconsole:emer -vsyslog:err -vfile:info
         set "$@" --remote=punix:"$DB_SOCK"
-        set "$@" --remote=db:Open_vSwitch,Open_vSwitch,manager_options
         set "$@" --private-key=db:Open_vSwitch,SSL,private_key
         set "$@" --certificate=db:Open_vSwitch,SSL,certificate
         set "$@" --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert
@@ -229,6 +228,17 @@ start_forwarding () {
            fi
            start_daemon "$OVS_VSWITCHD_PRIORITY" "$OVS_VSWITCHD_WRAPPER" "$@"
     fi
+
+    # Now that ovs-vswitchd has started and completed its initial
+    # configuration, tell ovsdb-server to conenct to the remote managers.  We
+    # used to do this at ovsdb-server startup time, but waiting for
+    # ovs-vswitchd to finish configuring means that remote managers see less
+    # churn in the database at startup or restart.  (For example, managers
+    # won't briefly see empty datapath-id or ofport columns for records that
+    # exist at startup.)
+    action "Enabling remote OVSDB managers" \
+       ovs-appctl -t ovsdb-server ovsdb-server/add-remote \
+           db:Open_vSwitch,Open_vSwitch,manager_options
 }
 
 ## ---- ##
-- 
1.7.10.4

_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to