From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Het Gala <het.gala@nutanix.com>
Cc: Peter Xu <peterx@redhat.com>,
qemu-devel@nongnu.org, farosas@suse.de, armbru@redhat.com
Subject: Re: [PATCH] Make 'uri' optional for migrate QAPI
Date: Fri, 26 Jan 2024 14:30:43 +0000 [thread overview]
Message-ID: <ZbPCExBqdWqAwbUh@redhat.com> (raw)
In-Reply-To: <238e2577-931a-418d-8af3-b1461e7b126c@nutanix.com>
On Fri, Jan 26, 2024 at 07:40:12PM +0530, Het Gala wrote:
> Hi everyone, I was trying to wrap around on how to write a migration test or to mock migration.
> I see there are a couple of migration tests already written, but most of them focuses on just getting the uri and parsing uri to start the migration.
> I have a couple of questions for starters like me who is attempting to write test cases for the first time:
>
> 1. Do I need to make a whole new test or just edit one of the tests that is using uri, and instead send in 'MigrateChannel' struct and parse the necessary information out of it ?
I think this option is best. We have two code paths - 'uri' and
'MigrateChannel', we we just need coverage of that new path.
So modifying some of the existing test cases to use MigrateChannel
gives us that coverage without harming existing coverage. This is
more time efficient than adding extra tests.
> 2. Do I need to add tests for unix, fd too with the modified syntax ?
I don't think so. When using the legacy 'uri' syntax (which all tests
already do), we convert to MigrateChannel internally, then the rest
of migration uses the MigrateChannel. IOW, we already have coverage
of unix/fd/etc.
All we're lacking is validation that the very first entrypoint allows
MigrateChannel. We can prove that with a single test that uses
MigrateChannel
> 3. Do I also need to add test to ensure - uri and channels both
> cannot be used simultaneously ? (based on the above patch)
Yes, its a worthwhile sanity check. There are a few intentional
failure tests in migrate-test.c.
> 4. Is there updated document in Qemu to follow latest practices on how to write migration tests?
Not that I know of
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2024-01-26 14:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-23 6:42 [PATCH] Make 'uri' optional for migrate QAPI Het Gala
2024-01-23 6:47 ` Het Gala
2024-01-23 8:21 ` Daniel P. Berrangé
2024-01-24 1:43 ` Peter Xu
2024-01-24 4:33 ` Het Gala
2024-01-26 14:10 ` Het Gala
2024-01-26 14:30 ` Daniel P. Berrangé [this message]
2024-01-29 20:30 ` Michael Tokarev
2024-01-29 20:56 ` Fabiano Rosas
2024-01-30 1:35 ` Peter Xu
2024-01-30 6:45 ` Michael Tokarev
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=ZbPCExBqdWqAwbUh@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=farosas@suse.de \
--cc=het.gala@nutanix.com \
--cc=peterx@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).