Am 09.10.2015 um 20:24 hat Max Reitz geschrieben:
> 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.It should stop people from using it in production, but it shouldn't stop them from using it for development and testing. We know that child-add/del is probably not the interface that we want to have in the end (and I would like to avoid accumulating tons of compatibility commands once we have what we want). If the COLO people say that they need an experimental command in order to make progress, that's fine with me. I think we'll all agree that while 'blockdev-add' can't reasonably be used in production yet, without it we couldn't have made much of the progress in the block layer that we made in the past year. If COLO people are in the same situation, let's give them what they need, without setting an unwanted interface in stone. > 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. Experimental features in management tools (e.g. in some feature branch) can use them, they just can't rely on it keeping working. > (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”) "Hey, look, two new functions for an incomplete feature! Use them if you want to help with development, but otherwise stay clear of them." Kevin
pgphkXMXP2Ki6.pgp
Description: PGP signature
