* Max Reitz (mre...@redhat.com) wrote: > On 09.10.2015 18:42, Dr. David Alan Gilbert wrote: > > * Max Reitz (mre...@redhat.com) wrote: > >> On 08.10.2015 08:15, Markus Armbruster wrote: > >>> Max Reitz <mre...@redhat.com> 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 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. > >>>> > >>>> 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 either. > >>> > >>> 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 that is > >>>> actually visible to the user (compare x-image in blkverify and blkdebug, > >>>> 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 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 making > >> 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? > > > > Because it lets people move forward; the COLO series is pretty huge, there > > already seem to be side discussions spawning off about dynamic > > reconfiguration > > 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. “I want to change quorum's options while > adding/removing children” can easily be accomplished with an additional > 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 “Hey, look, we have these two new functions you can > use!” and then, two versions later we remove them because we have a > general reconfiguration option, and we'll say “It's your own fault for > using experimental functions” if someone complains. That sounds > hypocritical to me, but I'm probably being to “legal” here. > > (i.e. it's more like “Hey, look, two new cool functions! But don't use > them.” which sounds like a contradiction to me, whereas it actually > means “Feel free to use them but don't blame us”) > > 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-.
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 (df5b2adb7398d71016ee469f71e52075ed95e04e) which is much worse than it starting out there. Dave > > Max > > > but it > > does remove their right to moan if it changes. > > > > Dave > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK