qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Fabiano Rosas <farosas@suse.de>
To: Het Gala <het.gala@nutanix.com>, qemu-devel@nongnu.org
Cc: marcandre.lureau@redhat.com, thuth@redhat.com,
	lvivier@redhat.com, pbonzini@redhat.com, peterx@redhat.com
Subject: Re: [PATCH v2 1/3] qtest: migration: Enhance qtest migration functions to support 'channels' argument
Date: Mon, 26 Feb 2024 10:01:56 -0300	[thread overview]
Message-ID: <87bk83bcqj.fsf@suse.de> (raw)
In-Reply-To: <1988bb0f-6ebe-4335-b761-d11313c772fd@nutanix.com>

Het Gala <het.gala@nutanix.com> writes:

> On 24/02/24 1:42 am, Fabiano Rosas wrote:
>> Het Gala<het.gala@nutanix.com>  writes:
>>
>>> Introduce support for adding a 'channels' argument to migrate_qmp_fail,
>>> migrate_incoming_qmp and migrate_qmp functions within the migration qtest
>>> framework, enabling enhanced control over migration scenarios.
>> Can't we just pass a channels string like you did in the original series
>> with migrate_postcopy_prepare?
>>
>> We'd change migrate_* functions like this:
>>
>>    void migrate_qmp(QTestState *who, const char *uri, const char *channels,
>>                     const char *fmt, ...)
>>    {
>>    ...
>>        g_assert(!qdict_haskey(args, "uri"));
>>        if (uri) {
>>            qdict_put_str(args, "uri", uri);
>>        }
>>    
>>        g_assert(!qdict_haskey(args, "channels"));
>>        if (channels) {
>>            qdict_put_str(args, "channels", channels);
>>        }
>>    }
>>
>> Write the test like this:
>>
>>    static void test_multifd_tcp_none_channels(void)
>>    {
>>        MigrateCommon args = {
>>            .listen_uri = "defer",
>>            .start_hook = test_migrate_precopy_tcp_multifd_start,
>>            .live = true,
>>            .connect_channels = "'channels': [ { 'channel-type': 'main',"
>>                                "      'addr': { 'transport': 'socket',"
>>                                "                'type': 'inet',"
>>                                "                'host': '127.0.0.1',"
>>                                "                'port': '0' } } ]",
>>            .connect_uri = NULL;
>>                                 
>>        };
>>        test_precopy_common(&args);
>>    }
>
> this was the same first approach that I attempted. It won't work because
>
> The final 'migrate' QAPI with channels string would look like
>
> { "execute": "migrate", "arguments": { "channels": "[ { "channel-type": 
> "main", "addr": { "transport": "socket", "type": "inet", "host": 
> "10.117.29.84", "port": "4000" }, "multifd-channels": 2 } ]" } }
>
> instead of
>
> { "execute": "migrate", "arguments": { "channels": [ { "channel-type": 
> "main", "addr": { "transport": "socket", "type": "inet", "host": 
> "10.117.29.84", "port": "4000" }, "multifd-channels": 2 } ] } }
>
> It would complain, that channels should be an *array* and not a string.
>
> So, that's the reason parsing was required in qtest too.
>
> I would be glad to hear if there are any ideas to convert /string -> 
> json object -> add it inside qdict along with uri/ ?
>

Isn't this what the various qobject_from_json do? How does it work with
the existing tests?

    qtest_qmp_assert_success(to, "{ 'execute': 'migrate-incoming',"
                             "  'arguments': { "
                             "      'channels': [ { 'channel-type': 'main',"
                             "      'addr': { 'transport': 'socket',"
                             "                'type': 'inet',"
                             "                'host': '127.0.0.1',"
                             "                'port': '0' } } ] } }");

We can pass this^ string successfully to QMP somehow...

>>    static void do_test_validate_uri_channel(MigrateCommon *args)
>>    {
>>        QTestState *from, *to;
>>        g_autofree char *connect_uri = NULL;
>>    
>>        if (test_migrate_start(&from, &to, args->listen_uri, &args->start)) {
>>            return;
>>        }
>>    
>>        wait_for_serial("src_serial");
>>    
>>        if (args->result == MIG_TEST_QMP_ERROR) {
>>            migrate_qmp_fail(from, args->connect_uri, args->connect_channels, "{}");
>>        } else {
>>            migrate_qmp(from, args->connect_uri, args->connect_channels, "{}");
>>        }
>>    
>>        test_migrate_end(from, to, false);
>>    }
>>
>> It's better to require test writers to pass in their own uri and channel
>> strings. Otherwise any new transport added will require people to modify
>> these conversion helpers.
> I agree with your point here. I was thinking to have a general but a 
> hacky version of migrate_uri_parse() but that too seemed like a 
> overkill. I don't have a better solution to this right now
>> Also, using the same string as the user would use in QMP helps with
>> development in general. One could refer to the tests to see how to
>> invoke the migration or experiment with the string in the tests during
>> development.
>
> For examples, I think - enough examples with 'channel' argument are 
> provided where 'migrate' QAPI is defined. users can directly copy the 
> qmp command from there itself.
>
>
> Regards,
>
> Het Gala


  parent reply	other threads:[~2024-02-26 13:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 15:25 [PATCH v2 0/3] qtest: migration: Add tests for introducing 'channels' argument in migrate QAPIs Het Gala
2024-02-23 15:25 ` [PATCH v2 1/3] qtest: migration: Enhance qtest migration functions to support 'channels' argument Het Gala
2024-02-23 15:57   ` Het Gala
2024-02-23 20:12   ` Fabiano Rosas
2024-02-24 12:48     ` Het Gala
2024-02-24 15:54       ` Het Gala
2024-02-26 13:01       ` Fabiano Rosas [this message]
2024-02-26 19:34         ` Het Gala
2024-02-26 20:24           ` Het Gala
2024-02-29  1:17             ` Fabiano Rosas
2024-02-29 21:51               ` Fabiano Rosas
2024-03-01  8:49               ` Het Gala
2024-03-01 12:47                 ` Het Gala
2024-03-01 13:33                   ` Fabiano Rosas
2024-02-23 15:25 ` [PATCH v2 2/3] qtest: migration: Add negative validation tests for 'uri' and 'channels' Het Gala
2024-02-23 15:25 ` [PATCH v2 3/3] qtest: migration: Start migration with 'channels' argument Het Gala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bk83bcqj.fsf@suse.de \
    --to=farosas@suse.de \
    --cc=het.gala@nutanix.com \
    --cc=lvivier@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).