Re: [Qemu-devel] [PATCH 0/9] monitor: enable OOB by default

[Markus Armbruster <armbru@redhat.com>]

Peter Xu <peterx@redhat.com> writes:

> On Tue, Jul 17, 2018 at 08:08:55PM +0800, Peter Xu wrote:
>
> [...]
>
>> > 
>> > Whatever we don't address right away we should at least mark FIXME in
>> > the source code.
>> > 
>> > Assuming my list is complete, and my assessments correct, then we're
>> > quite close to the point where we can enable OOB.  But since rc1 is
>> > tomorrow already, I feel enabling it in 3.0 has become unrealistic.  I
>> > understand we need it sooner rather than later for postcopy recovery.
>> > However, the current state should be servicable for teaching OOB to
>> > libvirt: just follow the recommendation to supply "id" (libvirt always
>> > does anyway), pretend COMMAND_DROPPED doesn't exist, and pretend flow
>> > control isn't an issue.
>> 
>> I guess the thing is not about COMMAND_DROPPED; it's about we're going
>> to drop the x-oob parameter.  Now we can only use that parameter to
>> enable out-of-band, and after we enable it by default we possibly want
>> to remove that x-oob parameter.  So we'd better provide a constant way
>> for libvirt to enable out-of-band first (and now I'll assume the
>> "exec-oob" interface won't change again).  But yes I think we can do
>> that after 3.0.

Yes, x-oob will go away right when OOB transitions from experimental to
supported.

I don't expect the request interface (exec-oob) to change, except we
might still make "id" mandatory.  Libvirt won't care, as it always
supplies "id".

If having to enable OOB with x-oob hampers libvirt work, I'd be willing
to enable OOB by default early in the 3.1 development cycle.  We can
always go back to disabled by default for the 3.1 release in case we
fail at getting it ready for 3.1,

> Btw, note that patches 4-7 might still be candidates of bug fixes for
> existing out-of-band feature.  It'll drop COMMAND_DROPPED event, but
> IMHO it's still better than having a broken flow control for it (and
> dropping event declaration is pretty safe even clients implemented
> them).  Though the changes are not trivial, so I'll leave the decision
> to you on whether we'll still consider them as 3.0 material.  Anyway,
> please feel free to let me know if you want me to post them
> separately.

Yes, COMMAND_DROPPED is flawed, and I dislike shipping flawed stuff as
much as you do.  However, it's clearly documented as flawed, and to get
it, you have to enable OOB with x-oob, where the x- clearly marks this
as experimental.

I think I'd rather not rock the boat now.