From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57012) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1am0sm-0001sY-5M for qemu-devel@nongnu.org; Fri, 01 Apr 2016 11:21:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1am0si-00051q-4N for qemu-devel@nongnu.org; Fri, 01 Apr 2016 11:21:08 -0400 References: <1457578181-27111-1-git-send-email-xiecl.fnst@cn.fujitsu.com> <1457578181-27111-3-git-send-email-xiecl.fnst@cn.fujitsu.com> <56E653E0.9030808@cn.fujitsu.com> <56EA06E0.7000409@cn.fujitsu.com> <56EA7C62.3090000@cn.fujitsu.com> <20160317094831.GA2504@work-vm> <56EA7F39.9060504@cn.fujitsu.com> <56FAA168.9090304@redhat.com> <56FAA2C4.3000002@redhat.com> <56FAA47A.2020801@redhat.com> <56FBEBA3.9070305@redhat.com> From: Max Reitz Message-ID: <56FE91D5.9030701@redhat.com> Date: Fri, 1 Apr 2016 17:20:53 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hdwb1E73WvJuTTkcR5KRMW72h0c02eh9w" Subject: Re: [Qemu-devel] [PATCH v12 2/3] quorum: implement bdrv_add_child() and bdrv_del_child() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia , Eric Blake , Wen Congyang , "Dr. David Alan Gilbert" Cc: Kevin Wolf , Changlong Xie , zhanghailiang , qemu block , Jiang Yunhong , Dong Eddie , qemu devel , Markus Armbruster , Gonglei , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hdwb1E73WvJuTTkcR5KRMW72h0c02eh9w Content-Type: multipart/mixed; boundary="iGUo3j9Dxiamnjn6ji5Botujn6O1Bvic4" From: Max Reitz To: Alberto Garcia , Eric Blake , Wen Congyang , "Dr. David Alan Gilbert" Cc: Changlong Xie , qemu devel , Kevin Wolf , Stefan Hajnoczi , Markus Armbruster , Dong Eddie , Jiang Yunhong , qemu block , zhanghailiang , Gonglei Message-ID: <56FE91D5.9030701@redhat.com> Subject: Re: [PATCH v12 2/3] quorum: implement bdrv_add_child() and bdrv_del_child() References: <1457578181-27111-1-git-send-email-xiecl.fnst@cn.fujitsu.com> <1457578181-27111-3-git-send-email-xiecl.fnst@cn.fujitsu.com> <56E653E0.9030808@cn.fujitsu.com> <56EA06E0.7000409@cn.fujitsu.com> <56EA7C62.3090000@cn.fujitsu.com> <20160317094831.GA2504@work-vm> <56EA7F39.9060504@cn.fujitsu.com> <56FAA168.9090304@redhat.com> <56FAA2C4.3000002@redhat.com> <56FAA47A.2020801@redhat.com> <56FBEBA3.9070305@redhat.com> In-Reply-To: --iGUo3j9Dxiamnjn6ji5Botujn6O1Bvic4 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: quoted-printable On 31.03.2016 13:42, Alberto Garcia wrote: > On Wed 30 Mar 2016 05:07:15 PM CEST, Max Reitz wrote: >>> I also have another (not directly related) question: why not simply >>> use the node name when removing children? I understood that the idea >>> was that it's possible to have the same node attached twice to the >>> same Quorum, but can you actually do that? And what's the use case? >> >> What I like about using the child role name is that it automatically >> prevents you from specifying a node that is not a child of the given >> parent. >=20 > Right, but checking if a node is not a child and returning an error is > very simple. And it doesn't require the user to keep track of the node > name *and* the child role name. Yes. But I think that you need to know parent and child anyway if you want to modify (delete) an edge in the graph. Also, it may be possible to have multiple parents per node. Actually, it is already possible because the BB-BDS relationship is modeled as a parent-child relationship. Thus, I'm not sure whether it would be sufficient to specify a single node if you want to delete a single edge. > Unless I'm forgetting something this would be the first time we expose > the child role name in the API, that's why I'm wondering if it's > something worth doing. Well, the roles are kind of exposed already. It's exactly what you specify in -drive or blockdev-add. >> Which makes me notice that it might be a good idea to require the user= >> to specify the child's role when adding a new child. In this version >> of this series (where only quorum is supported), the children are just= >> inserted in numerical order (first free slot is taken first), but >> maybe the user wants to insert them in a different order. >=20 > For the Quorum case it totally makes sense to let the user choose the > position of the new child. >=20 > But for creating a Quorum array in the first place we don't require > that, the order is the one that the user provides, and the user does no= t > need to know about the child role names at that point. Depends. If you create an empty quorum BDS and then add the children using the QAPI command introduced in this series, you are right. But if you add children along with creating the quorum BDS (be it via -drive or via blockdev-add), one has to specify the child role names. Max --iGUo3j9Dxiamnjn6ji5Botujn6O1Bvic4-- --hdwb1E73WvJuTTkcR5KRMW72h0c02eh9w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW/pHVAAoJEDuxQgLoOKyt5UkH/3GFHVlyQFdfPDtHTK3Utscm fplBDE8vGaNKasUx4Sm9Dn43PZhJ1+voGeS/HZ0j4vfgMr+FoUWrPKmEDBQZ9g9o PBmR8y22ovtGOE3IEY6VQFmB8/qJzhfApPMmJE+qx8bTEWFeo3ifSmpOP452mzpZ GnK7ouNl8EfDl38s6JimnphgkOt3RwYHOIwajtyNrM9IpkUYobWkZpjl775WJdZP EcPlRjIScoN+jEvcuxoUspi+l8ZkBRVB0odPsExIWzwInQJuHQTrJRoUMSu7A9V1 cLv17Br03Sns4+4B3iDoOQPcd3EIkkDBTkv1LfUxXN8oMHhkzG3DNKacmtf+0cw= =t0LW -----END PGP SIGNATURE----- --hdwb1E73WvJuTTkcR5KRMW72h0c02eh9w--