Re: [PATCH 0/4] QOM: Singleton interface

[Markus Armbruster <armbru@redhat.com>]

Looked at this thread again to refresh my memory on the proposed
singleton interface, and found I have something to add.

Peter Xu <peterx@redhat.com> writes:

> On Tue, Oct 29, 2024 at 04:04:50PM +0000, Daniel P. Berrangé wrote:
>> I tend to feel that having MigrationState exist for the whole lifetime
>> of QEMU is a bug, forced on us by the unfortunate need to call
>> migrate-set-parameters/capabilities separately from the migrate
>> command, and by the need to query migrate info an arbitrary amount of
>> time after it finishes.
>> 
>> This puts libvirt in the awkward position of having to manually reset
>> all migration parameters, just to ensure earlier settings don't
>> accidentally affect a future migration operation :-( This is a design
>> that encourages mistakes.
>
> I think it would still be easy to add "cap" & "params" arguments support
> for the "migrate" QMP command without breaking the current API, iff that
> helps in whatever form.  When present, it simply applies the caps and/or
> param list first before invoking the migrate command, fail the command if
> cap / param check fails.
>
> But I'm not sure whether that's a concern at all for Libvirt, if what
> Libvirt currently does is having separate "migrate-set-*" commands prior to
> the "migrate".  I may have overlooked the real issue behind on how that
> could complicate Libvirt.

I think Daniel's point is that the interface's reliance on global state
makes it awkward to use.

Migration configuration is global state.  It's split into "capabilities"
and "parameters", but that's detail.  We have commands to query and
change this state.

When Libvirt connects to a QEMU process, it has no idea what the global
migration configuration is.  To get it into a known state, it has to set
*everything*.  It cannot rely on defaults.

It even has to set things it doesn't know!  When we add a new parameter
to QEMU, libvirt needs to be updated to reset it to its default even
when libvirt has no need for it.  When you use a version of libvirt that
lacks this update, it remains whatever it was.  The migration interface
becomes accidentally stateful at the libvirt level, which is
undesirable.

Compare this to the more modern interface we have for other long-running
tasks: jobs.

There is a job-specific command that creates the job: blockdev-backup,
block-commit, blockdev-mirror, block-stream, blockdev-create,
snapshot-save, snapshot-load, snapshot-delete, ...  Each command takes
the entire job configuration as arguments.  Libvirt does not need
updating for new parameters: these simply remain at their default
values.

Bonus: there are generic commands to control and monitor jobs:
job-pause, job-resume, job-cancel, job-complete, job-dismiss,
job-finalize, query-jobs.

[...]