On 03/23/2018 08:41 PM, Peter Xu wrote:
There have been quite a few patch ideas across multiple threads related to
OOB fallout. Hopefully I can keep straight which patches are intended for
2.12 (anything that fixes a bug, like this one, is a good candidate,
I'll mark patches with "for-2.12" if there are.
and it
would be nice if we can undo the temporary reversion of exposing OOB if we
can solve all the issues that iotests exposed).
IMHO it'll still be risky considering what has already reported.
Here's my plan, hopefully to make everyone happy - we keep OOB turned
off for 2.12 and even later. In 2.13, I'll post some new patches to
add a new monitor parameter to allow user to enable OOB explicitly,
otherwise we never enable it. After all, for now the only real user
should be postcopy. Then we don't need to struggle around all these
mess. What do you think?
If you're going to add a CLI parameter that must be specified for OOB to
even be advertised, then it is MUCH less invasive to existing clients
(it does mean that opting in to OOB now requires the command line
argument AND the capability request during qmp_capabilities) - as such,
enabling the opt-in during 2.12 is less controversial, and I see no
reason to defer it to 2.13, especially if you want to maximize testing
of the new feature to shake out the bugs it encounters.
If you want to be cautious, name the command-line parameter --x-oob for
now, we can rename it later to drop the x- prefix, or remove the
parameter altogether if we decide by opting in via merely
qmp_capabilities is sufficient.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
