From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkcLj-0002g8-GD for qemu-devel@nongnu.org; Fri, 09 Oct 2015 14:25:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkcLi-00089p-26 for qemu-devel@nongnu.org; Fri, 09 Oct 2015 14:24:59 -0400 References: <1442907862-21376-1-git-send-email-wency@cn.fujitsu.com> <1442907862-21376-4-git-send-email-wency@cn.fujitsu.com> <56157599.9020608@redhat.com> <87vbahq41u.fsf@blackfin.pond.sub.org> <5617E78C.5080906@redhat.com> <20151009164224.GA28665@work-vm> From: Max Reitz Message-ID: <56180668.1090609@redhat.com> Date: Fri, 9 Oct 2015 20:24:40 +0200 MIME-Version: 1.0 In-Reply-To: <20151009164224.GA28665@work-vm> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="x2cEitnm5bA9UrmdIUrH2EkjXnlXNrb5A" Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v5 3/4] qmp: add monitor command to add/remove a child List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Dr. David Alan Gilbert" Cc: Kevin Wolf , Yang Hongyang , Alberto Garcia , zhanghailiang , Jiang Yunhong , Dong Eddie , Markus Armbruster , qemu devel , Gonglei , Stefan Hajnoczi , qemu block This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --x2cEitnm5bA9UrmdIUrH2EkjXnlXNrb5A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09.10.2015 18:42, Dr. David Alan Gilbert wrote: > * Max Reitz (mreitz@redhat.com) wrote: >> On 08.10.2015 08:15, Markus Armbruster wrote: >>> Max Reitz writes: >>> >>>> On 22.09.2015 09:44, Wen Congyang wrote: >>>>> The new QMP command name is x-blockdev-child-add, and x-blockdev-ch= ild-del. >>>>> It justs for adding/removing quorum's child now, and don't support = all >>>>> kinds of children, >>>> >>>> It does support all kinds of children for quorum, doesn't it? >>>> >>>>> nor all block drivers. So it is experimental now= =2E >>>> >>>> Well, that is not really a reason why we would have to make it >>>> experimental. For instance, blockdev-add (although some might argue = it >>>> actually is experimental...) doesn't support all block drivers eithe= r. >>> >>> Yup, and not calling it x-blockdev-add until it's done was a mistake.= >>> People tried using it, then found its current limitations the painful= >>> way. Not nice. >> >> I knew I should have written s/some might/Markus does/. ;-) >> >>>> The reason I am hesitant of adding an experimental QMP interface tha= t is >>>> actually visible to the user (compare x-image in blkverify and blkde= bug, >>>> which are not documented and not to be used by the user) is twofold:= >>>> >>>> (1) At some point we have to say "OK, this is good enough now" and m= ake >>>> it stable. What would that point be? Who can guarantee that we >>>> wouldn't want to make any interface changes after that point? >>> >>> Nobody can, just like for any other interface. So? >> >> The main question is "what would that point be". As I can see you're >> arguing that that point would be "once people want to use it", but I'm= >> arguing that people want to use it today or we wouldn't need this >> interface at all. >> >> I'm against adding external experimental interface because having >> external interface indicates that someone wants to use them, but makin= g >> them experimental indicates that nobody should use them. >> >> This interface is added for the COLO series. The documentation added i= n >> patch 5 there explains usage of COLO with x-child-add. I don't think >> that should be there, because it's experimental. But why have an >> external interface if nobody should use it anyway? >=20 > Because it lets people move forward; the COLO series is pretty huge, th= ere > already seem to be side discussions spawning off about dynamic reconfig= uration > of stuff, who knows how long those will take to pan out. Yes, and my point is that with these functions (blockdev-child-{add,del}) the result of that side discussion doesn't matter. > Adding the experimental stuff makes it easier for people to try and > get some feedback on. The thing is, I cannot imagine any feedback that would necessitate an incompatible change. =E2=80=9CI want to change quorum's options while adding/removing children=E2=80=9D can easily be accomplished with an addi= tional optional parameter. But I do know that we want to keep things experimental exactly because there can be feedback which I cannot imagine right now. > If everyone turns out to love it then it only takes a trivial patch to = promote > it; if people actually realise there is a better interface then it's > no problem to change it either - x- doesn't stop any one using it, But it should, shouldn't it? No management tool should be using an x- command, as far as I know. And these are functions which are clearly designed for management tools. If management tools are indeed free to use x- functions, then I'm completely fine with making these experimental for now. It's just that it looks to me like =E2=80=9CHey, look, we have these two new functions y= ou can use!=E2=80=9D and then, two versions later we remove them because we have= a general reconfiguration option, and we'll say =E2=80=9CIt's your own faul= t for using experimental functions=E2=80=9D if someone complains. That sounds hypocritical to me, but I'm probably being to =E2=80=9Clegal=E2=80=9D her= e. (i.e. it's more like =E2=80=9CHey, look, two new cool functions! But don'= t use them.=E2=80=9D which sounds like a contradiction to me, whereas it actual= ly means =E2=80=9CFeel free to use them but don't blame us=E2=80=9D) tl;dr: May management tools use x- functions? And is it actually conceivable for them to do so? If so, my whole argument becomes moot, so let's make these functions x-. Mainly I'd like to know about some example where we had an x- function in the past. Markus seemed to imply that was the case. Max > but = it > does remove their right to moan if it changes. >=20 > Dave --x2cEitnm5bA9UrmdIUrH2EkjXnlXNrb5A 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 iQEcBAEBCAAGBQJWGAZoAAoJEDuxQgLoOKyt+KQH/jbbuYK5IKdzTqQgFDS/OoKo YQ4GEaHmFq4i+t4W9pgkRi3EYahgBrAq5rYw/JRiuT7KkCiU1O7NT+XOq50TIGd2 SH32obvDeEqg+CcbLkFQKezUhET/bwywlj+RTQiNy6HQQfIq9+ubudoBENZ+fIRl OWhv6eodYcxrzo6j2w2zNnRATHrmXdqUSj0FynC40UKy2z2eYEiDXVjvxWuMoCfg OmERYrMLM2MB0JRfWk8jDedPBaKg/HNq6DjosTjA6LzBs4v/TxtTIHICP8M2SP9D jlIvJWesHCv6Cj01GN+r0Z2st+p5e13oWbdeIzIz1cCJ1IAa4MCIKnZsTIZhmgc= =3hBj -----END PGP SIGNATURE----- --x2cEitnm5bA9UrmdIUrH2EkjXnlXNrb5A--