All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Sascha Silbe <silbe@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Kevin Wolf <kwolf@redhat.com>, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH for-2.6?] qemu-iotests: iotests: fail hard if not run via "check"
Date: Mon, 18 Apr 2016 09:19:32 +0200	[thread overview]
Message-ID: <87ega39yez.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <1460633543-7366-1-git-send-email-silbe@linux.vnet.ibm.com> (Sascha Silbe's message of "Thu, 14 Apr 2016 13:32:23 +0200")

Sascha Silbe <silbe@linux.vnet.ibm.com> writes:

> Running an iotests-based Python test directly might appear to work,
> but may fail in subtle ways and is insecure:
>
> - It creates files with predictable file names in a world-writable
>   location (/var/tmp).
>
> - Tests expect the environment to be set up by check. E.g. 041 and 055
>   may take the wrong code paths if QEMU_DEFAULT_MACHINE is not
>   set. This can lead to false negatives.
>
> Instead fail hard and tell the user we want to be run via "check".

Are the problems serious enough to warrant rejecting the attempt to run
the tests directly outright?

Judging from your description, I'm inclined to "no".

> Signed-off-by: Sascha Silbe <silbe@linux.vnet.ibm.com>
> Reviewed-by: Bo Tu <tubo@linux.vnet.ibm.com>
> ---
> It's possible to fix iotests.py to work even outside of check, but
> that requires reimplementing parts of what check currently does. I'd
> prefer not to do that this late in the cycle.
>
> It would be nice to have this in 2.6, just in case someone even tries
> running a Python-based test directly instead of using ./check like for
> the shell-based tests. But it's not crucial.
> ---
>  tests/qemu-iotests/iotests.py | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tests/qemu-iotests/iotests.py b/tests/qemu-iotests/iotests.py
> index 0c0b533..8c7138f 100644
> --- a/tests/qemu-iotests/iotests.py
> +++ b/tests/qemu-iotests/iotests.py
> @@ -46,7 +46,7 @@ if os.environ.get('QEMU_OPTIONS'):
>  
>  imgfmt = os.environ.get('IMGFMT', 'raw')
>  imgproto = os.environ.get('IMGPROTO', 'file')
> -test_dir = os.environ.get('TEST_DIR', '/var/tmp')
> +test_dir = os.environ.get('TEST_DIR')
>  output_dir = os.environ.get('OUTPUT_DIR', '.')
>  cachemode = os.environ.get('CACHEMODE')
>  qemu_default_machine = os.environ.get('QEMU_DEFAULT_MACHINE')
> @@ -441,6 +441,10 @@ def verify_quorum():
>  def main(supported_fmts=[], supported_oses=['linux']):
>      '''Run tests'''
>  
> +    if test_dir is None or qemu_default_machine is None:
> +        sys.stderr.write('Please run this test via ./check\n')
> +        sys.exit(os.EX_USAGE)
> +
>      debug = '-d' in sys.argv
>      verbosity = 1
>      verify_image_format(supported_fmts)

Aha, you're not actually rejecting the attempt to run the tests
directly, you're merely requiring two environment variables.  That's
okay with me.  However, the commit message should explain it.  I'd also
rephrase the error message to something like

    <program_name>: TEST_DIR and QEMU_DEFAULT_MACHINE must be set in environment
    The easiest way to do that is running the test via the check script.

  parent reply	other threads:[~2016-04-18  7:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14 11:32 [Qemu-devel] [PATCH for-2.6?] qemu-iotests: iotests: fail hard if not run via "check" Sascha Silbe
2016-04-14 22:11 ` Max Reitz
2016-04-19 12:22   ` Sascha Silbe
2016-04-19 19:06     ` Max Reitz
2016-04-19 19:32       ` Sascha Silbe
2016-04-20  6:55       ` Markus Armbruster
2016-04-20  8:37         ` Sascha Silbe
2016-04-18  7:19 ` Markus Armbruster [this message]
2016-04-19 11:59   ` Sascha Silbe
2016-04-19 12:25     ` Markus Armbruster
2016-04-19 16:49       ` Sascha Silbe
2016-04-20  8:38         ` Kevin Wolf
2016-04-20  8:51           ` Sascha Silbe
2016-04-19 19:34 ` [Qemu-devel] [PATCH for-2.6? v2] " Sascha Silbe
2016-05-11 15:43   ` Max Reitz

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=87ega39yez.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=silbe@linux.vnet.ibm.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 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.