Peter Xu <[email protected]> writes: > On Mon, Dec 15, 2025 at 07:00:13PM -0300, Fabiano Rosas wrote: >> The listen_uri parameter is supposed to be used for the incoming >> migration while connect_uri for the outgoing migration. This is well >> documented in the header file. >> >> However, due to -incoming "defer", some tests set listen-uri = >> "defer", which is fine. But then, being without another parameter to >> define the uri to be use in migrate_incoming, some tests have been >> misusing connect_uri. >> >> Add a separate flag to denote "defer" and spare the tests from passing >> the string. Change the usage of listen_uri to it's original purpose. >> >> Signed-off-by: Fabiano Rosas <[email protected]> >> --- >> tests/qtest/migration/compression-tests.c | 12 +++---- >> tests/qtest/migration/cpr-tests.c | 17 +++++++--- >> tests/qtest/migration/file-tests.c | 38 ++++++++++++++++------- >> tests/qtest/migration/framework.c | 12 +++---- >> tests/qtest/migration/framework.h | 7 +++++ >> tests/qtest/migration/misc-tests.c | 4 +-- >> tests/qtest/migration/precopy-tests.c | 26 ++++++++++------ >> tests/qtest/migration/tls-tests.c | 16 +++++----- >> 8 files changed, 85 insertions(+), 47 deletions(-) > > Makes sense. > > But there's one missing? I'm staring at a tree where wholeset applied, I > can still see: > > static void test_mode_exec(char *name, MigrateCommon *args) > { > g_autofree char *uri = g_strdup_printf("file:%s/%s", tmpfs, > FILE_TEST_FILENAME); > g_autofree char *listen_uri = g_strdup_printf("defer"); <------------- >
Missed that one. > args->connect_uri = uri; > args->listen_uri = listen_uri; > ... > } > > The other question is, after this patch, can we assume connect_uri and > listen_uri should always be the same? Can we merge the two already into > "uri"? > Yes, because the tests run on the same machine, so the endpoint is always the same. I don't think we do any tricks of making them mismatch just to see it burn. It could be useful for testing maybe, or not. I'll check and if they're indeed always the same I can merge them, it would clarify the code a lot. > For the latter - not a request to do it in this series, I suggest we land > this series without keep growing, or you'll have endless pain rebasing.. > However no hurt to discuss the next step so you can send them afterwards if > you see fit.
