Re: [PATCH V3 11/16] migration: cpr-transfer mode

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Nov 20, 2024 at 11:12:51AM -0500, Steven Sistare wrote:
> On 11/20/2024 4:38 AM, Daniel P. Berrangé wrote:
> > On Tue, Nov 19, 2024 at 03:32:55PM -0500, Steven Sistare wrote:
> > > 
> > > This begs the question, should we allow channels to be specified in hmp migrate
> > > commands and for -incoming, in a very simple way?  Like with a prefix naming
> > > the channel.  And eliminate the -cpr-uri argument. Examples:
> > > 
> > > (qemu) migrate -d main:tcp:0:44444,cpr:unix:cpr.sock
> > > 
> > > qemu -incoming main:tcp:0:44444,cpr:unix:cpr.sock
> > > qemu -incoming main:defer,cpr:unix:cpr.sock
> > 
> > As a general rule, if you ever find yourself asking "should we add more
> > magic parsing logic" to the command line argv, the answer should always
> > be 'no'.
> > 
> > Any command line args where we need to have more expressive formatting
> > are getting converted to accept JSON syntax, backed by QAPI modelling.
> > We were anticipating that '-incoming' should ideally end up deprecated
> > except for the plain "defer" option, on the expectation that any non-
> > trivial use of migration needs HMP/QMP regardless. If there's a vaild
> > use case for something other than 'defer', then we need to QAPI-ify
> > -incoming with JSON syntax IMHO.
> 
> Hi Daniel, thank you for the guidance.
> 
> CPR needs to open and read its channel before the monitor is available,
> so the cpr uri must be passed on the command line in some form.  Is that
> sufficient reason to violate your general rule?

Not really. IMHO it is still viable to define a CLI arg using JSON and
QAPI, even if there's no need to use it from QMP.

> If not, would you support the -cpr-uri command-line option?
> 
> If not, that leaves us with QAPI-ifying -incoming, which is messy, because
> MigrationChannel has a nested type structure.  We would need to define
> a flattened list of properties and duplicate much of the existing specification.
> Unless, it could take a JSON object as its value, with all the {}:" syntax,
> and be parsed with visit_type_MigrationChannel.  But I do not see any
> precedent for that in other command-line arguments.

Using JSON syntax exclusively is exactly what I'm suggesting. While some
command line args have invented ways to express nested types, we don't
really want to be in that business anymore. Anything complex should be
JSON syntax on the command line. We support this with -object, -device,
-audiodev, -netdev, -blockdev already, and eventually expect everything
to support JSON syntax.

You can see this in practice in libvirt, where we'll prefer JSON syntax
for any args that support it:

  https://gitlab.com/libvirt/libvirt/-/blob/master/tests/qemuxmlconfdata/x86_64-q35-graphics.x86_64-latest.args

The approach to retrofitting to an existing cli arg is pretty crude but
effective in QEMU. Just look if the first character is '{' and if so,
switch to QAPI based parsing instead of legacy parsing.

> Of these, I still think "qemu -incoming main:tcp:0:44444,cpr:unix:cpr.sock"
> is the least worst option.  We could further simplify it by allowing the
> option multiple times, and only recognizing the additional "cpr" prefix.
> 
>   qemu -incoming tcp:0:44444 -incoming cpr:unix:cpr.sock
>   qemu -incoming defer -incoming cpr:unix:cpr.sock
> 
> Your further comments, please.  I need a way forward that you and other
> maintainers will support.

In terms of where we wire up CPR, -incoming or -cpr-uri is fairly
arbitrary and I'm not seeing (easy) better answers.

The (hard) better answer, would potentally be to leverage '-object'
to create the migration state object but that would be a massive
pile of work, that is unreasonable to ask you to experiment with.

> 
> > Yes, there's still the question of HMP, but personally I'm fine with
> > leaving feature gaps in HMP and expecting people to use QMP. HMP shares
> > all the same flaws as our old approach to the CLI, of needing to invent
> > arbitrary magic syntaxes which has proved to be an undesirble path to
> > take in general. I see HMP as being there for the 80% common / simple
> > cases, and if you need to go beyond that, then QMP is there for you.
> 
> Fine with me.
> 
> - Steve
> 

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 :|