On Fri, Oct 25, 2024 at 02:43:06PM +0100, Daniel P. Berrangé wrote: > > The migration QAPI design has always felt rather odd to me, in that we > have perfectly good commands "migrate" & "migrate-incoming" that are able > to accept an arbitrary list of parameters when invoked. Instead of passing > parameters to them though, we instead require apps use the separate > migreate-set-parameters/capabiltiies commands many times over to set > global variables which the later 'migrate' command then uses. > > The reason for this is essentially a historical mistake - we copied the > way we did it from HMP, which was this way because HMP was bad at supporting > arbitrary customizable paramters to commands. I wish we hadn't copied this > design over to QMP. > > To bring it back on topic, we need QMP on the dest to set parameters, > because -incoming was limited to only take the URI. > > If the "migrate-incoming" command accepted all parameters directly, > then we could use QAPI visitor to usupport a "-incoming ..." command > that took an arbitrary JSON document and turned it into a call to > "migrate-incoming". > > With that we would never need QMP on the target for cpr-exec, avoiding > this ordering poblem you're facing....assuming we put processing of > -incoming at the right point in the code flow > > Can we fix this design and expose the full configurability on the > CLI using QAPI schema & inline JSON, like we do for other QAPI-ified > CLI args. > > It seems entirely practical to me to add parameters to 'migrate-incoming' > in a backwards compatible manner and deprecate set-parameters/capabilities
Incidentally, if we were going to evolve the migration API at all, then it probably ought to start making use of the async job infrastructure we have available. This is use by block jobs, and by the internal snapshot commands, and was intended to be used for any case where we had a long running operation triggered by a command. Migration was a poster-child example of what its intended for, but was left alone when we first introduced the job APIs. The 'job-cancel' API would obsolete 'migrate-cancel'. The other interestnig thing is that the job framework creates a well defined lifecycle for a job, that allows querying information about the job after completeion, but without QEMU having to keep that info around forever. ie once a job has finished, an app can query info about completion, and when it no longer needs that info, it can call 'job-dismiss' to tell QEMU to discard it. If "MigrationState" were associated a job, then it would thus have a clear 'creation' and 'deletion' time. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
