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: Wed, 28 Feb 2024 22:17:51 -0300 [thread overview]
Message-ID: <87o7c0rruo.fsf@suse.de> (raw)
In-Reply-To: <894b5da4-0af1-4ca0-b8a7-da288bb20774@nutanix.com>
Het Gala <het.gala@nutanix.com> writes:
> On 27/02/24 1:04 am, Het Gala wrote:
>>
>>
>> On 26/02/24 6:31 pm, Fabiano Rosas wrote:
>>> Het Gala<het.gala@nutanix.com> writes:
>>>
>>>> On 24/02/24 1:42 am, Fabiano Rosas wrote:
>>>> 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...
>>
>> I think, here in qtest_qmp_assert_success, we actually can pass the
>> whole QMP command, and it just asserts that return key is present in
>> the response, though I am not very much familiar with qtest codebase
>> to verify how swiftly we can convert string into an actual QObject.
>>
>> [...]
>>
> I tried with qobject_from_json type of utility functions and the error I
> got was this :
>
> migration-test: /rpmbuild/SOURCES/qemu/include/qapi/qmp/qobject.h:126:
> qobject_type: Assertion `QTYPE_NONE < obj->base.type && obj->base.type <
> QTYPE__MAX' failed.
>
> And I suppose this was the case because, there are only limited types of
> QTYPE available
>
> typedefenumQType{
> QTYPE_NONE,
> QTYPE_QNULL,
> QTYPE_QNUM,
> QTYPE_QSTRING,
> QTYPE_QDICT,
> QTYPE_QLIST,
> QTYPE_QBOOL,
> QTYPE__MAX,
> } QType;
>
> And 'channels' is a mixture of QDICT and QLIST and hence it is not able
> to easily convert from string to json.
>
> Thoughts on this ?
I'm not sure what you tried. This works:
g_assert(!qdict_haskey(args, "channels"));
if (channels) {
channels_obj = qobject_from_json(channels, errp);
qdict_put_obj(args, "channels", channels_obj);
}
And in the test:
.connect_channels = "[ { 'channel-type': 'main',"
" 'addr': { 'transport': 'socket',"
" 'type': 'inet',"
" 'host': '127.0.0.1',"
" 'port': '0' } } ]",
.listen_uri = "tcp:127.0.0.1:0",
.result = MIG_TEST_QMP_ERROR
However, the real issue is how to inject the port for the source
migration. The example above only works for the tests that are expected
to fail. For a test that should pass, 0 as a port does not work.
I'm thinking it might be better to alter migrate_qmp like this:
void migrate_qmp(QTestState *from, QTestState *to, const char *channels,
const char *fmt, ...)
Invocations would be:
migrate_qmp(from, to, NULL, "{uri: %s}", connect_uri);
migrate_qmp(from, to, args->channels, "{}");
In this last case, if the test provided a port, we use it, otherwise we
resolve it from the 'to' instance and put it in the QDict directly.
I'll play with this a bit more tomorrow, let me know what you think.
next prev parent reply other threads:[~2024-02-29 1:18 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
2024-02-26 19:34 ` Het Gala
2024-02-26 20:24 ` Het Gala
2024-02-29 1:17 ` Fabiano Rosas [this message]
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=87o7c0rruo.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.