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


  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 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).