From patchwork Tue May 23 04:14:10 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?6auY5q2j5Lyf?= X-Patchwork-Id: 765734 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 3wX2d44JtRz9sP3 for ; Tue, 23 May 2017 14:30:16 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=163.com header.i=@163.com header.b="qJxjNCV7"; dkim-atps=neutral Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 03B9F959; Tue, 23 May 2017 04:30:13 +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 2982D5AC for ; Tue, 23 May 2017 04:30:12 +0000 (UTC) X-Greylist: delayed 00:15:26 by SQLgrey-1.7.6 Received: from m50-138.163.com (m50-138.163.com [123.125.50.138]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 49619134 for ; Tue, 23 May 2017 04:30:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=Date:From:Subject:Mime-Version:Message-ID; bh=sxOiT A7+drbgXCEbeHx2H9ACvpqhqcwUnA7IRDZvPZM=; b=qJxjNCV7v36siicUKeWO+ QFkYixyJLZlsEyvNMFVC08WYmVE4Zol1xd8GDJWtqsdyEVLrL1NjES5XFLdnG3+Q voTbfP7zOMzT46yd5pCs70caDLKSWObaydMjiD5PtaXQyWp4sTz0ZlMJozRrixkm PQhUBCdAEx1+i3nXMFjhbo= Received: from gaozhengweiWork (unknown [123.125.26.234]) by smtp1 (Coremail) with SMTP id C9GowACnHCUxtyNZqSg6AA--.851S2; Tue, 23 May 2017 12:14:41 +0800 (CST) Date: Tue, 23 May 2017 12:14:10 +0800 From: "multi_task@163.com" To: "Numan Siddique" References: <20170517154507.31840-1-blp@ovn.org>, , <5e9de8ff.1b77.15c1e66b9c6.Coremail.multi_task@163.com>, X-Priority: 3 X-GUID: 679802CF-8466-48DF-89FA-2E0C40F14AD5 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 7, 164[cn] Mime-Version: 1.0 Message-ID: <201705231214106097244@163.com> X-CM-TRANSID: C9GowACnHCUxtyNZqSg6AA--.851S2 X-Coremail-Antispam: 1Uf129KBjvJXoW3GF45ZFyxAFW3uryDKFy5CFg_yoWxAr48pr Zayr43ur4UJr17t34kWw47JayxZrn7Cr1aywsxtr1Ika90y3WIqr1Sy3ZYkFyqqFyrJr48 XrWDZws5u3y7AFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jO3kZUUUUU= X-Originating-IP: [123.125.26.234] X-CM-SenderInfo: xpxo3x5bwd2yi6rwjhhfrp/1tbiMBHg1lWBawJIkAACsw X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_PSBL, RP_MATCHES_RCVD autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Content-Filtered-By: Mailman/MimeDel 2.1.12 Cc: ovs dev Subject: Re: [ovs-dev] [PATCH] Supporting ovn-northd service HA depend on OVNDB-HA 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 Hi Numan, Thank you very much, I had pushed the patch new version https://github.com/openvswitch/ovs/pull/178 Thanks Zhengwei multi_task@163.com From: Numan Siddique Date: 2017-05-22 15:33 To: 高正伟 CC: Ben Pfaff; ovs dev Subject: Re: Re: [ovs-dev] [PATCH] Supporting ovn-northd service HA depend on OVNDB-HA On Fri, May 19, 2017 at 7:21 AM, 高正伟 wrote: Thanks Numan I think that supporting OVNDB and ovn-northd HA depend on one pacemaker is an idea, In case of thinking OVN-HA, user will not individually care about OVNDB or ovn-northd HA. Hi Zhangwei, I do agree with you. But what I am trying to say is to make it configurable. I tested with your patch again with tripleo and it is having few issues. 1. Since you are not passing "--ovn-manage-ovsdb=no", when "ovn-ctl stop_northd" is called, it also stops ovsdb-servers. We probably don't want to stop ovsdb-servers unless, pacemaker calls "stop" action. 2. When a master node is demoted, ovn-northd is not stopped since "ovn-ctl stop_northd" code is not hit. I tested with the below modifications and applying this patch - https://patchwork.ozlabs.org/patch/765224/. It is working as expected. Can you please test on your side and resubmit another version if it is fine with you. If the user wants to manage ovn_northd using the ocf resources, he could pass manage_northd=yes while creating the resource. -----------------------cut here ------------------------------------- I tried this patch and it works. In the case of OpenStack and Tripleo, puppet is used to create and manage the pacemaker resources for OVN [1] and it also starts ovn-northd as a pacemaker service with colocation constraint set to the virtual ip created for the OVN DB servers. I think it makes more sense to start ovn-northd based on a flag (like START_NORTHD) so that the user or the configuration systems can chose. Thanks Numan [1] - https://review.openstack.org/#/c/372274/10/manifests/profile/pacemaker/ovn_northd.pp -- 2.10.2 _______________________________________________ dev mailing list dev@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev Acked-by: Numan Siddique Tested-by: Numan Siddique diff --git a/ovn/utilities/ovndb-servers.ocf b/ovn/utilities/ovndb-servers.ocf index 40c5541..018d904 100755 --- a/ovn/utilities/ovndb-servers.ocf +++ b/ovn/utilities/ovndb-servers.ocf @@ -7,6 +7,7 @@ : ${NB_MASTER_PROTO_DEFAULT="tcp"} : ${SB_MASTER_PORT_DEFAULT="6642"} : ${SB_MASTER_PROTO_DEFAULT="tcp"} +: ${MANAGE_NORTHD_DEFAULT="no"} CRM_MASTER="${HA_SBIN_DIR}/crm_master -l reboot" CRM_ATTR_REPL_INFO="${HA_SBIN_DIR}/crm_attribute --type crm_config --name OVN_REPL_INFO -s ovn_ovsdb_master_server" OVN_CTL=${OCF_RESKEY_ovn_ctl:-${OVN_CTL_DEFAULT}} @@ -15,6 +16,7 @@ NB_MASTER_PORT=${OCF_RESKEY_nb_master_port:-${NB_MASTER_PORT_DEFAULT}} NB_MASTER_PROTO=${OCF_RESKEY_nb_master_protocol:-${NB_MASTER_PROTO_DEFAULT}} SB_MASTER_PORT=${OCF_RESKEY_sb_master_port:-${SB_MASTER_PORT_DEFAULT}} SB_MASTER_PROTO=${OCF_RESKEY_sb_master_protocol:-${SB_MASTER_PROTO_DEFAULT}} +MANAGE_NORTHD=${OCF_RESKEY_manage_northd:-${MANAGE_NORTHD_DEFAULT}} # Invalid IP address is an address that can never exist in the network, as # mentioned in rfc-5737. The ovsdb servers connects to this IP address till @@ -90,6 +92,14 @@ ovsdb_server_metadata() { + + + If set to yes, manages ovn-northd service. ovn-northd will be started in + the master node. + + manage ovn-northd service + + @@ -122,12 +132,17 @@ ovsdb_server_notify() { # the right thing at startup ocf_log debug "ovndb_server: $host_name is the master" ${CRM_ATTR_REPL_INFO} -v "$host_name" - # Startup ovn-northd service - ${OVN_CTL} start_northd + if [ "$MANAGE_NORTHD" = "yes" ]; then + # Startup ovn-northd service + ${OVN_CTL} --ovn-manage-ovsdb=no start_northd + fi else - # Stop ovn-northd service - ${OVN_CTL} stop_northd + if [ "$MANAGE_NORTHD" = "yes" ]; then + # Stop ovn-northd service. Set --ovn-manage-ovsdb=no so that + # ovn-ctl doesn't stop ovsdb-servers. + ${OVN_CTL} --ovn-manage-ovsdb=no stop_northd + fi # Synchronize with the new master ocf_log debug "ovndb_server: Connecting to the new master ${OCF_RESKEY_CRM_meta_notify_promote_uname}" ${OVN_CTL} demote_ovnnb --db-nb-sync-from-addr=${MASTER_IP} \ @@ -289,6 +304,13 @@ ovsdb_server_start() { } ovsdb_server_stop() { + if [ "$MANAGE_NORTHD" = "yes" ]; then + # Stop ovn-northd service in case it was running. This is required + # when the master is demoted. For other cases, it would be a no-op. + # Set --ovn-manage-ovsdb=no so that ovn-ctl doesn't stop ovsdb-servers. + ${OVN_CTL} --ovn-manage-ovsdb=no stop_northd + fi + ovsdb_server_check_status case $? in $OCF_NOT_RUNNING) return ${OCF_SUCCESS};; -------------------------------------------------------------------------- Thanks Numan Thanks. 在 2017-05-18 20:53:22，"Numan Siddique" 写道： On Wed, May 17, 2017 at 9:15 PM, Ben Pfaff wrote: From: Zhengwei Gao As ovn-northd servcie parse network element between ovnnb_db and ovnsb_db, it ensures ovn-northd service connecting to ovnnb_db and ovnsb_db. OVNDB-HA was supported with pacemaker, ovn-northd service will be failover fllowing OVNDB-HA. --- This was posted as a github pull request: https://github.com/openvswitch/ovs/pull/176 ovn/utilities/ovndb-servers.ocf | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ovn/utilities/ovndb-servers.ocf b/ovn/utilities/ovndb-servers.ocf index 908cb3c17d84..40c55411e828 100755 --- a/ovn/utilities/ovndb-servers.ocf +++ b/ovn/utilities/ovndb-servers.ocf @@ -122,8 +122,12 @@ ovsdb_server_notify() { # the right thing at startup ocf_log debug "ovndb_server: $host_name is the master" ${CRM_ATTR_REPL_INFO} -v "$host_name" + # Startup ovn-northd service + ${OVN_CTL} start_northd else + # Stop ovn-northd service + ${OVN_CTL} stop_northd # Synchronize with the new master ocf_log debug "ovndb_server: Connecting to the new master ${OCF_RESKEY_CRM_meta_notify_promote_uname}" ${OVN_CTL} demote_ovnnb --db-nb-sync-from-addr=${MASTER_IP} \