ovs-ctl: Connect to remote OVSDB managers only after ovs-vswitchd starts.
authorBen Pfaff <blp@nicira.com>
Wed, 10 Apr 2013 16:53:54 +0000 (09:53 -0700)
committerBen Pfaff <blp@nicira.com>
Thu, 11 Apr 2013 01:15:02 +0000 (18:15 -0700)
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 <jmerrick@vmware.com>
CC: Amar Padmanabhan <amar@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Ansis Atteka <aatteka@nicira.com>
Bug #15983.

AUTHORS
utilities/ovs-ctl.in

diff --git a/AUTHORS b/AUTHORS
index a425baa..32f9890 100644 (file)
--- a/AUTHORS
+++ b/AUTHORS
@@ -96,6 +96,7 @@ Alan Shieh              ashieh@nicira.com
 Alban Browaeys          prahal@yahoo.com
 Alex Yip                alex@nicira.com
 Alexey I. Froloff       raorn@altlinux.org
+Amar Padmanabhan        amar@nicira.com
 Amey Bhide              abhide@nicira.com
 André Ruß               andre.russ@hybris.com
 Andreas Beckmann        debian@abeckmann.de
index a82518c..bd7db4b 100755 (executable)
@@ -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
 }
 
 ## ---- ##