All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Max Reitz <mreitz@redhat.com>, qemu-block@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 3/4] iotests: Add @error to wait_until_completed
Date: Fri, 13 Sep 2019 18:53:32 -0400	[thread overview]
Message-ID: <d5231f69-9c50-c1d8-6680-5e835b907861@redhat.com> (raw)
In-Reply-To: <20190912135632.13925-4-mreitz@redhat.com>



On 9/12/19 9:56 AM, Max Reitz wrote:
> Callers can use this new parameter to expect failure during the
> completion process.
> 
> Signed-off-by: Max Reitz <mreitz@redhat.com>
> ---
>  tests/qemu-iotests/iotests.py | 18 ++++++++++++------
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index b26271187c..300347c7c8 100644
> --- a/tests/qemu-iotests/iotests.py
> +++ b/tests/qemu-iotests/iotests.py
> @@ -745,15 +745,20 @@ class QMPTestCase(unittest.TestCase):
>          self.assert_no_active_block_jobs()
>          return result
>  
> -    def wait_until_completed(self, drive='drive0', check_offset=True, wait=60.0):
> +    def wait_until_completed(self, drive='drive0', check_offset=True, wait=60.0,
> +                             error=None):
>          '''Wait for a block job to finish, returning the event'''
>          while True:
>              for event in self.vm.get_qmp_events(wait=wait):
>                  if event['event'] == 'BLOCK_JOB_COMPLETED':
>                      self.assert_qmp(event, 'data/device', drive)
> -                    self.assert_qmp_absent(event, 'data/error')
> -                    if check_offset:
> -                        self.assert_qmp(event, 'data/offset', event['data']['len'])
> +                    if error is None:
> +                        self.assert_qmp_absent(event, 'data/error')
> +                        if check_offset:
> +                            self.assert_qmp(event, 'data/offset',
> +                                            event['data']['len'])
> +                    else:
> +                        self.assert_qmp(event, 'data/error', error)
>                      self.assert_no_active_block_jobs()
>                      return event
>                  elif event['event'] == 'JOB_STATUS_CHANGE':
> @@ -771,7 +776,8 @@ class QMPTestCase(unittest.TestCase):
>          self.assert_qmp(event, 'data/type', 'mirror')
>          self.assert_qmp(event, 'data/offset', event['data']['len'])
>  
> -    def complete_and_wait(self, drive='drive0', wait_ready=True):
> +    def complete_and_wait(self, drive='drive0', wait_ready=True,
> +                          completion_error=None):
>          '''Complete a block job and wait for it to finish'''
>          if wait_ready:
>              self.wait_ready(drive=drive)
> @@ -779,7 +785,7 @@ class QMPTestCase(unittest.TestCase):
>          result = self.vm.qmp('block-job-complete', device=drive)
>          self.assert_qmp(result, 'return', {})
>  
> -        event = self.wait_until_completed(drive=drive)
> +        event = self.wait_until_completed(drive=drive, error=completion_error)
>          self.assert_qmp(event, 'data/type', 'mirror')
>  
>      def pause_wait(self, job_id='job0'):
> 

toot toot more optional parameters. lay them at the altar of
noncommittal python design.

I completely forget what the difference between unittest.TestCase and
qtest.QEMUQtestMachine is and why they each have job management methods.

Well, OK: the VM one is a simple subclass of the general-purpose VM
machine to add some more useful stuff. the unittest one implements some
general-purpose behavior with asserts that only work in the unittest world.

Still,

It's a little fun that we've got run_job as well as cancel_and_wait,
wait_until_completed, wait_ready, wait_ready_and_cancel, pause_wait and
pause_job and they all seem to implement job run-state logic management
a little differently.

Probably no bugs there, I bet.

*cough* Not your fault, anyway, so please take this accolade:

Reviewed-by: John Snow <jsnow@redhat.com>


(it's probably my fault)


  reply	other threads:[~2019-09-13 22:54 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-12 13:56 [Qemu-devel] [PATCH 0/4] mirror: Do not dereference invalid pointers Max Reitz
2019-09-12 13:56 ` [Qemu-devel] [PATCH 1/4] " Max Reitz
2019-09-13 22:43   ` John Snow
2019-09-18 15:16   ` Vladimir Sementsov-Ogievskiy
2019-09-12 13:56 ` [Qemu-devel] [PATCH 2/4] blkdebug: Allow taking/unsharing permissions Max Reitz
2019-09-18 16:01   ` Vladimir Sementsov-Ogievskiy
2019-09-19 16:49     ` Max Reitz
2019-09-12 13:56 ` [Qemu-devel] [PATCH 3/4] iotests: Add @error to wait_until_completed Max Reitz
2019-09-13 22:53   ` John Snow [this message]
2019-09-16  7:56     ` Max Reitz
2019-09-18 16:09   ` Vladimir Sementsov-Ogievskiy
2019-09-12 13:56 ` [Qemu-devel] [PATCH 4/4] iotests: Add test for failing mirror complete Max Reitz
2019-09-18 16:30   ` Vladimir Sementsov-Ogievskiy
2019-09-19 16:51     ` Max Reitz
2019-09-18 18:46   ` John Snow
2019-09-19 16:58     ` Max Reitz
2019-09-19 17:02       ` John Snow
2019-09-19 17:06         ` Max Reitz
2019-09-18 15:38 ` [Qemu-devel] [PATCH 0/4] mirror: Do not dereference invalid pointers Vladimir Sementsov-Ogievskiy
2019-09-19 16:45   ` Max Reitz
2019-09-19 16:50     ` Vladimir Sementsov-Ogievskiy

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=d5231f69-9c50-c1d8-6680-5e835b907861@redhat.com \
    --to=jsnow@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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 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.