On 08/13/2018 04:35 AM, Markus Armbruster wrote:
Or, here's an idea:
Keep the name @base and @top, but add a new '*by-node':'bool' parameter,
defaulting to false for now, but perhaps with a deprecation warning that
we'll switch the default to true in one release and delete the parameter
altogether in an even later release. When false, @base and @top are
filenames, as before; when true, @base and @top are node names instead.
Introspectible, nicer names in the long run, and avoids having to detect a
user providing two mutually-exclusive options at once.
I don't like options that completely change the semantics of other
options, but maybe that's just personal preference.
I happen to share it.
Okay, we'll ditch that idea as a non-starter.
Anyway, thinking about the long term for block-commit is useless, the
command is just broken (for example, the @device option doesn't make any
sense) and will have to be replaced. But libvirt needs something _now_
for the -blockdev support, so I decided to add this as a quick hack
before we get the proper replacement.
I think it makes more sense to create a new blockdev-commit (which
would be a name more in line with the other block job commands) and
deprecate the old block-commit command as a whole.
Okay, looks like a good plan for the long term, and thus a good
rationale for the short-term choices. The commit message could call that
out.
Has any progress been made on the plan to support defaults in QAPI, so
that we could get rid of the has_* parameters?
No. It's one of those things that keep getting pushed out by more
important or urgent stuff.
I expect it to be straightforward, if tedious.
In part, Marc-Andre's work to get conditional compilation in has gotten
us closer, in that we can have 'name':{'type':'foo','if':'...'} instead
of 'name':'type', since that dict for conditional compilation is also
where we would stick in default values.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
