qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH v5 3/4] qmp: add monitor command to


From: Markus Armbruster
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v5 3/4] qmp: add monitor command to add/remove a child
Date: Thu, 08 Oct 2015 08:15:25 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Max Reitz <address@hidden> 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.

> 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 x- prefix enables work spanning multiple releases.  Until the
feature is complete, we have a hard time seeing the whole picture, and
therefore the risk of interface mistakes is higher than normal.  Once
it's complete, we drop the x-.

>                                                                   Would
>     we actually remember to revisit this function once in a while and
>     consider making it stable?

Has that been a problem in the past?

If the feature is of any use, there's always been mounting pressure to
finish the job and drop the x-.  If it's of no use, not dropping the x-
would do no harm.  The opposite, actually.

> (2) While marking things experimental *should* keep people from using it
>     in their tools, nobody can guarantee that it *does* keep them from
>     doing so. So we may find ourselves in the situation of having to
>     keep a compatibility interface for an experimental feature...

You can't force people not to do stupid things, but you *can* improve
their chances at avoiding them.  Clearly marking experimental stuff
improves chances.

> For the second point, you should also consider how useful this feature
> is to management tools. Just being able to remove and attach children
> from a quorum node seems very useful on its own. I don't see why we
> should wait for having support for other block drivers; also, for most
> block drivers there is no meaningful way of adding or removing children
> as nicely as that is possible for quorum.

Okay, this is an argument I might be able to buy.

> E.g. you may have a block filter in the future where you want to
> exchange its child BDS. This exchange should be an atomic operation, so
> we cannot use this interface there anyway. For quorum, such an exchange
> does not need to be atomic, since you can just add the new child first
> and remove the old one afterwards.
>
> So maybe in the future we get some block driver other than quorum for
> which adding and removing children (as opposed to atomically exchanging
> them) makes sense, but for now I can only see quorum. Therefore, that
> this works for quorum only is in my opinion not a reason to make it
> experimental. I think we actually want to keep it that way.

Are you telling us the existing interface is insufficiently general?
That the general interface neeeds to support atomic replacement?

If yes, why isn't the general interface is what we should do for quorum?
Delete is atomic replacement by nothing, add is atomic replacement of
nothing.

> So the question would then be: What ways can you imagine to change this
> interface, which would necessitate an incompatible change, therefore
> calling for an experimental interface?

Yes, that's an important question.

Another important question is whether this is the interface we want.

A secondary question is whether the incompleteness of the implementation
demands an x- to warn users.

> (My point is that with such an experimental interface, management tools
> cannot use it, even though it'd be a very nice functionality to have)

How much work is it to finish the job?  Unless it's a substantial chunk,
debating x- is much ado about nothing: just finish the job already :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]