From: Het Gala <het.gala@nutanix.com>
To: Fabiano Rosas <farosas@suse.de>, qemu-devel@nongnu.org
Cc: marcandre.lureau@redhat.com, thuth@redhat.com,
lvivier@redhat.com, pbonzini@redhat.com, peterx@redhat.com
Subject: Re: [PATCH v3 4/7] Add migrate_set_ports into migrate_qmp to change migration port number
Date: Wed, 6 Mar 2024 20:36:14 +0530 [thread overview]
Message-ID: <0238e330-cb9f-4d72-9ca8-ca7a1b51dddf@nutanix.com> (raw)
In-Reply-To: <87sf13s9yz.fsf@suse.de>
[-- Attachment #1: Type: text/plain, Size: 4404 bytes --]
On 06/03/24 8:06 pm, Fabiano Rosas wrote:
> Het Gala<het.gala@nutanix.com> writes:
>
>> Add a migrate_set_ports() function that from each QDict, fills in
>> the port in case it was 0 in the test.
>> Handle a list of channels so we can add a negative test that
>> passes more than one channel.
>>
>> Signed-off-by: Het Gala<het.gala@nutanix.com>
>> Suggested-by: Fabiano Rosas<farosas@suse.de>
>> ---
>> tests/qtest/migration-helpers.c | 26 ++++++++++++++++++++++++++
>> 1 file changed, 26 insertions(+)
>>
>> diff --git a/tests/qtest/migration-helpers.c b/tests/qtest/migration-helpers.c
>> index 478c1f259b..df4978bf17 100644
>> --- a/tests/qtest/migration-helpers.c
>> +++ b/tests/qtest/migration-helpers.c
>> @@ -17,6 +17,8 @@
>> #include "qapi/qapi-visit-sockets.h"
>> #include "qapi/qobject-input-visitor.h"
>> #include "qapi/error.h"
>> +#include "qapi/qmp/qlist.h"
>> +
> Extra line here. This is unwanted because it sometimes trips git into
> thinking there's a conflict here when another patch changes the
> surrounding lines.
Ack, that makes sense
>>
>> #include "migration-helpers.h"
>>
>> @@ -73,6 +75,29 @@ migrate_get_socket_address(QTestState *who, const char *parameter)
>> return result;
>> }
>>
>> +static void migrate_set_ports(QTestState *to, QList *channelList)
>> +{
>> + g_autofree char *addr = NULL;
>> + g_autofree char *addr_port = NULL;
>> + QListEntry *entry;
>> +
>> + addr = migrate_get_socket_address(to, "socket-address");
>> + addr_port = g_strsplit(addr, ":", 3)[2];
> Will this always do the right thing when the src/dst use different types
> of channels? If there is some kind of mismatch (say one side uses vsock
> and the other inet), it's better that this function doesn't touch the
> channels dict instead of putting garbage in the port field.
Yes you are right. This will fail if there is a mismatch in type of
channels.
Better idea would be to check if 'port' key is present in both, i.e. in
'addr'
as well as 'addrdict' and only then change the port ?
> Also what happens if the dst is using unix: or fd:?
yes in that case - how should the migration behaviour be ? src and dst
should be of the same type right
>> +
>> + QLIST_FOREACH_ENTRY(channelList, entry) {
>> + QDict *channel = qobject_to(QDict, qlist_entry_obj(entry));
>> + QObject *addr_obj = qdict_get(channel, "addr");
>> +
>> + if (qobject_type(addr_obj) == QTYPE_QDICT) {
>> + QDict *addrdict = qobject_to(QDict, addr_obj);
> You might not need these two lines if at the start you use:
>
> QDict *addr = qdict_get_dict(channel, "addr");
If you are commenting regarding this two lines:
+ if (qobject_type(addr_obj) == QTYPE_QDICT) {
+ QDict *addrdict = qobject_to(QDict, addr_obj);
then, I am not sure, because addrdict and addr is different right? Also addrdict can also
be a QList, like in the case of exec migration, it can be a list instead of dict
ex:
# -> { "execute": "migrate",
# "arguments": {
# "channels": [ { "channel-type": "main",
# "addr": { "transport": "exec",
# "args": [ "/bin/nc", "-p", "6000",
# "/some/sock" ] } } ] } }
>
>> + if (qdict_haskey(addrdict, "port") &&
>> + (strcmp(qdict_get_str(addrdict, "port"), "0") == 0)) {
>> + qdict_put_str(addrdict, "port", addr_port);
>> + }
>> + }
>> + }
>> +}
>> +
>> bool migrate_watch_for_events(QTestState *who, const char *name,
>> QDict *event, void *opaque)
>> {
>> @@ -143,6 +168,7 @@ void migrate_qmp(QTestState *who, QTestState *to, const char *uri,
>> if (!uri) {
>> connect_uri = migrate_get_socket_address(to, "socket-address");
>> }
>> + migrate_set_ports(to, NULL);
> migrate_set_ports is not prepared to take NULL. This breaks the tests in
> this commit. All individual commits should work, otherwise it will break
> bisecting.
Okay, so in that case, is it better to merge this with the next patch ?
because if I just
define the migrate_set_ports function and not use it anywhere, it gives
a warning/error
(depending upon what compiler is used)
>> qdict_put_str(args, "uri", uri ? uri : connect_uri);
>>
>> qtest_qmp_assert_success(who,
Regards,
Het Gala
[-- Attachment #2: Type: text/html, Size: 6864 bytes --]
next prev parent reply other threads:[~2024-03-06 15:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 10:49 [PATCH v3 0/7] qtest: migration: Add tests for introducing 'channels' argument in migrate QAPIs Het Gala
2024-03-06 10:49 ` [PATCH v3 1/7] Add 'to' object into migrate_qmp() Het Gala
2024-03-06 14:37 ` Fabiano Rosas
2024-03-06 10:49 ` [PATCH v3 2/7] Replace connect_uri and move migrate_get_socket_address inside migrate_qmp Het Gala
2024-03-06 14:37 ` Fabiano Rosas
2024-03-06 10:49 ` [PATCH v3 3/7] Add channels parameter in migrate_qmp_fail Het Gala
2024-03-06 14:40 ` Fabiano Rosas
2024-03-06 15:10 ` Het Gala
2024-03-06 10:49 ` [PATCH v3 4/7] Add migrate_set_ports into migrate_qmp to change migration port number Het Gala
2024-03-06 14:36 ` Fabiano Rosas
2024-03-06 15:06 ` Het Gala [this message]
2024-03-06 16:01 ` Fabiano Rosas
2024-03-06 19:36 ` Het Gala
2024-03-06 21:30 ` Het Gala
2024-03-07 11:37 ` Fabiano Rosas
2024-03-06 10:49 ` [PATCH v3 5/7] Add channels parameter in migrate_qmp Het Gala
2024-03-06 14:42 ` Fabiano Rosas
2024-03-06 15:31 ` Het Gala
2024-03-06 10:49 ` [PATCH v3 6/7] Add multifd_tcp_plain test using list of channels instead of uri Het Gala
2024-03-06 15:07 ` Fabiano Rosas
2024-03-06 18:40 ` Het Gala
2024-03-06 10:49 ` [PATCH v3 7/7] Add negative tests to validate migration QAPIs Het Gala
2024-03-06 15:08 ` Fabiano Rosas
2024-03-06 12:55 ` [PATCH v3 0/7] qtest: migration: Add tests for introducing 'channels' argument in migrate QAPIs 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=0238e330-cb9f-4d72-9ca8-ca7a1b51dddf@nutanix.com \
--to=het.gala@nutanix.com \
--cc=farosas@suse.de \
--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).