From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlY9P-0001Lh-DM for qemu-devel@nongnu.org; Mon, 12 Oct 2015 04:08:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlY9O-0000Ga-7j for qemu-devel@nongnu.org; Mon, 12 Oct 2015 04:08:07 -0400 Date: Mon, 12 Oct 2015 09:07:52 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20151012080752.GA2687@work-vm> 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> <56180668.1090609@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56180668.1090609@redhat.com> Content-Transfer-Encoding: quoted-printable 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: Max Reitz Cc: Kevin Wolf , Alberto Garcia , zhanghailiang , qemu block , Jiang Yunhong , Dong Eddie , Markus Armbruster , qemu devel , Gonglei , Stefan Hajnoczi , Yang Hongyang * Max Reitz (mreitz@redhat.com) wrote: > 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-= child-del. > >>>>> It justs for adding/removing quorum's child now, and don't suppor= t all > >>>>> kinds of children, > >>>> > >>>> It does support all kinds of children for quorum, doesn't it? > >>>> > >>>>> nor all block drivers. So it is experimental n= ow. > >>>> > >>>> Well, that is not really a reason why we would have to make it > >>>> experimental. For instance, blockdev-add (although some might argu= e it > >>>> actually is experimental...) doesn't support all block drivers eit= her. > >>> > >>> Yup, and not calling it x-blockdev-add until it's done was a mistak= e. > >>> People tried using it, then found its current limitations the painf= ul > >>> 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 t= hat is > >>>> actually visible to the user (compare x-image in blkverify and blk= debug, > >>>> which are not documented and not to be used by the user) is twofol= d: > >>>> > >>>> (1) At some point we have to say "OK, this is good enough now" and= make > >>>> 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 mak= ing > >> them experimental indicates that nobody should use them. > >> > >> This interface is added for the COLO series. The documentation added= in > >> 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, = there > > already seem to be side discussions spawning off about dynamic reconf= iguration > > of stuff, who knows how long those will take to pan out. >=20 > Yes, and my point is that with these functions > (blockdev-child-{add,del}) the result of that side discussion doesn't > matter. >=20 > > Adding the experimental stuff makes it easier for people to try and > > get some feedback on. >=20 > 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 ad= ditional > optional parameter. >=20 > But I do know that we want to keep things experimental exactly because > there can be feedback which I cannot imagine right now. >=20 > > If everyone turns out to love it then it only takes a trivial patch t= o 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, >=20 > 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. >=20 > 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= you can > use!=E2=80=9D and then, two versions later we remove them because we ha= ve a > general reconfiguration option, and we'll say =E2=80=9CIt's your own fa= ult 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 h= ere. > > (i.e. it's more like =E2=80=9CHey, look, two new cool functions! But do= n't use > them.=E2=80=9D which sounds like a contradiction to me, whereas it actu= ally > means =E2=80=9CFeel free to use them but don't blame us=E2=80=9D) >=20 > 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, s= o > let's make these functions x-. My guess is the libvirt guys wont take the code to drive the x- methods; but it still makes it easier if someone wants to try this stuff out, they wont need to apply 2/3 sets of COLO code and then any management tools. > 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. The RDMA code used to have x- for migration protocol and some of the capabilities; we've recently added Jason Herne's cpu throttling with similar x- flags (1626fee3bdbb295d5e8aff800f7621357bb376d6), and input-send-event got moved into the x- world (df5b2adb7398d71016ee469= f71e52075ed95e04e) which is much worse than it starting out there. Dave >=20 > Max >=20 > > bu= t it > > does remove their right to moan if it changes. > >=20 > > Dave >=20 >=20 -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK