"Dr. David Alan Gilbert" <dgilb...@redhat.com> writes: > * 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. > Adding the experimental stuff makes it easier for people to try and > get some feedback on. > 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 > does remove their right to moan if it changes.
Exactly.