From patchwork Mon Oct 14 06:10:48 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Numan Siddique X-Patchwork-Id: 1176007 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=openvswitch.org (client-ip=140.211.169.12; helo=mail.linuxfoundation.org; envelope-from=ovs-dev-bounces@openvswitch.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 46s7hs6rhbz9sPj for ; Mon, 14 Oct 2019 17:20:29 +1100 (AEDT) Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id B730E25AE; Mon, 14 Oct 2019 06:20:23 +0000 (UTC) X-Original-To: dev@openvswitch.org Delivered-To: ovs-dev@mail.linuxfoundation.org Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 211F5258F for ; Mon, 14 Oct 2019 06:11:10 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4626688E for ; Mon, 14 Oct 2019 06:11:07 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8D86310CC1E9 for ; Mon, 14 Oct 2019 06:11:06 +0000 (UTC) Received: from nummac.local (ovpn-116-161.sin2.redhat.com [10.67.116.161]) by smtp.corp.redhat.com (Postfix) with ESMTP id AA434F6EF; Mon, 14 Oct 2019 06:11:04 +0000 (UTC) From: nusiddiq@redhat.com To: dev@openvswitch.org Date: Mon, 14 Oct 2019 11:40:48 +0530 Message-Id: <20191014061048.3443-1-nusiddiq@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.65]); Mon, 14 Oct 2019 06:11:06 +0000 (UTC) X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [ovs-dev] [PATCH] ovsdb-server: Don't drop all connections on read/write status change. X-BeenThere: ovs-dev@openvswitch.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ovs-dev-bounces@openvswitch.org Errors-To: ovs-dev-bounces@openvswitch.org From: Numan Siddique The commit [1] force drops all connections when the db read/write status changes. Prior to the commit [1], when there was read/write status change, the existing jsonrpc sessions with 'db_change_aware' set to true, were not updated with the changed 'read_only' value. If the db status was changed to 'standby', the existing clients could still write to the db. In the case of pacemaker OVN HA, OVN OCF script 'start' action starts the ovsdb-servers in read-only state and later, it sets to read-write in the 'promote' action. We have observed that if some ovn-controllers connect to the SB ovsdb-server (in read-only state) just before the 'promote' action, the connection is not reset all the times and these ovn-controllers remain connected to the SB ovsdb-server in read-only state all the time. Even though the commit [1] calls 'ovsdb_jsonrpc_server_reconnect()' with 'forced' flag set to true when the db read/write status changes, somehow the FSM misses resetting the connections of these ovn-controllers. I think this needs to be addressed in the FSM. This patch doesn't address this FSM issue. Instead it changes the behavior of 'ovsdb_jsonrpc_server_set_read_only()' by setting the 'read_only' flag of all the jsonrpc sessions instead of forcefully resetting the connection. I think there is no need to reset the connection. In large scale production deployements with OVN, this results in unnecessary waste of CPU cycles as ovn-controllers will have to connect twice - once during 'start' action and again during 'promote'. [1] - 2a9679e3b2c6("ovsdb-server: drop all connections on read/write status change") Signed-off-by: Numan Siddique --- ovsdb/jsonrpc-server.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) diff --git a/ovsdb/jsonrpc-server.c b/ovsdb/jsonrpc-server.c index ddbbc2e94..066826959 100644 --- a/ovsdb/jsonrpc-server.c +++ b/ovsdb/jsonrpc-server.c @@ -80,6 +80,8 @@ static void ovsdb_jsonrpc_session_unlock_all(struct ovsdb_jsonrpc_session *); static void ovsdb_jsonrpc_session_unlock__(struct ovsdb_lock_waiter *); static void ovsdb_jsonrpc_session_send(struct ovsdb_jsonrpc_session *, struct jsonrpc_msg *); +static void ovsdb_jsonrpc_session_set_readonly_all( + struct ovsdb_jsonrpc_remote *remote, bool read_only); /* Triggers. */ static void ovsdb_jsonrpc_trigger_create(struct ovsdb_jsonrpc_session *, @@ -365,10 +367,13 @@ ovsdb_jsonrpc_server_set_read_only(struct ovsdb_jsonrpc_server *svr, { if (svr->read_only != read_only) { svr->read_only = read_only; - ovsdb_jsonrpc_server_reconnect(svr, true, - xstrdup(read_only - ? "making server read-only" - : "making server read/write")); + struct shash_node *node; + + SHASH_FOR_EACH (node, &svr->remotes) { + struct ovsdb_jsonrpc_remote *remote = node->data; + + ovsdb_jsonrpc_session_set_readonly_all(remote, read_only); + } } } @@ -670,6 +675,17 @@ ovsdb_jsonrpc_session_reconnect_all(struct ovsdb_jsonrpc_remote *remote, } } +static void +ovsdb_jsonrpc_session_set_readonly_all(struct ovsdb_jsonrpc_remote *remote, + bool read_only) +{ + struct ovsdb_jsonrpc_session *s, *next; + + LIST_FOR_EACH_SAFE (s, next, node, &remote->sessions) { + s->read_only = read_only; + } +} + /* Sets the options for all of the JSON-RPC sessions managed by 'remote' to * 'options'. *