From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [RFC] new LTP testrunner
Date: Tue, 17 Jul 2018 17:37:04 +0200 [thread overview]
Message-ID: <20180717153704.GA24297@rei> (raw)
In-Reply-To: <4457957.33743155.1531841330713.JavaMail.zimbra@redhat.com>
Hi!
> > It's there but not in the README, there is a sh backend that just runs
> > the tests in a localy executed shell see --help.
> >
> > But I would like to discourage running the testcases locally for any
> > test automation/CI.
>
> Can you elaborate? Assuming I don't crash, what is the negative
> of running locally?
We do have tests that invoke OOM as well in that case the test execution
framework may be hit as well. The filesystem tests can corrupt the fs we
are saving the logfiles and results to, etc.
This also means some of the tests cannot be really done at all, if the
testrunner is supposed to be running on a separate machine we can
possibly implement testcases for example for kexec, MCE, magic sysrq,
etc.
> > > The way we coped with (fatal) issues is pre-processing
> > > runtest files based on kernel version, package versions,
> > > architecture, etc.
> >
> > This is something I wanted to avoid if possible because it requires to
> > maintain a database which time consuming and prone to errors.
>
> True, but if you want to avoid wasting countless hours just
> on reboots due to known bugs, there probably isn't a better way.
>
> This might not be big deal for VMs, but some bare metal
> takes its time to come up.
Well yes, some big servers take ages to boot, the VMs are quite fast to
reboot compared to that.
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2018-07-17 15:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-17 11:43 [LTP] [RFC] new LTP testrunner Cyril Hrubis
2018-07-17 14:33 ` Jan Stancek
2018-07-17 14:45 ` Cyril Hrubis
2018-07-17 15:28 ` Jan Stancek
2018-07-17 15:37 ` Cyril Hrubis [this message]
2018-07-18 1:27 ` Daniel Sangorrin
2018-07-18 8:52 ` Cyril Hrubis
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=20180717153704.GA24297@rei \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
/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