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
next prev 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.