From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: "Luis R. Chamberlain" <mcgrof@kernel.org>
Cc: Amir Goldstein <amir73il@gmail.com>,
Jeff Mahoney <jeffm@suse.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
xfs <linux-xfs@vger.kernel.org>,
fstests <fstests@vger.kernel.org>,
Sasha Levin <Alexander.Levin@microsoft.com>,
Sasha Levin <levinsasha928@gmail.com>,
Valentin Rothberg <valentinrothberg@gmail.com>
Subject: Re: [ANN] oscheck: wrapper for fstests check.sh - tracking and working with baselines
Date: Fri, 13 Jul 2018 20:52:07 -0400 [thread overview]
Message-ID: <20180714005207.GF28610@thunk.org> (raw)
In-Reply-To: <20180713164420.GA3620@garbanzo.do-not-panic.com>
On Fri, Jul 13, 2018 at 09:44:20AM -0700, Luis R. Chamberlain wrote:
>
> We have a few options. One is share the entire results directory for
> a release / section, however this is rather big. For instance for a
> full v4.17.3 run this is about 292 MiB alone. I don't think this
> scales. IMHO lgogs should only be supplied onto bug reports, not this
> framework.
The results directory compress fairly well. A complete ext4 run (with
the configurations defined for gce-xfstests) is 101MB uncompressed,
and 2.3 MB as a tar.xz file. That's only 6 cents a month in Google
Cloud Storage, and for me it's worth it to keep them; it's
occasionally been interesting.
> The other option is to use -R xunit to generate the report in the
> specified unit. I have not yet run this, or tried it, however IIRC
> it does record success runs?
Yes, it does.
> Does it also keep logs? Hopefully not.
It does include some information, but not all of the information that
might be in the results directory.
% ls /tmp/results-ltm-20180709000722/ab/ext4/results-1k/results.xml
108 /tmp/results-ltm-20180709000722/ab/ext4/results-1k/results.xml
vs
% du -sh /tmp/results-ltm-20180709000722/ab/ext4/results-1k
3.0M /tmp/results-ltm-20180709000722/ab/ext4/results-1k
> Having the expunge files separately helps as we can annotate bug URLs to
> them optionally. Ie, we should be able to process both expunge lists
> and xunit file to construct a nice db schema to process results
> in a more easily viewable manner in the future.
I do this. You can see an example here with my annotations:
https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/test-appliance/files/root/fs/ext4/exclude
> So to establish a baseline, one first manually contstructs the expunge
> files needed to run a full test. In the future hopefully we can have
> a set of scripts to do all this for us.
Yep, I do this by using a command-line option when I run gce-xfstests
or kvm-xfstests to skip using the exclude files. It's definitely
useful.
> We'd have to then process that file to scrape out which tests were
> passed, if a user wanted that. Do we have scripts for processing
> xunit files?
I have some scripts which you may find useful. They can be found here:
https://github.com/tytso/xfstests-bld/tree/master/kvm-xfstests/test-appliance/files/usr/local/bin
https://github.com/tytso/xfstests-bld/tree/master/kvm-xfstests/test-appliance/files/usr/lib/python2.7
This is what I use to parse through the xunit xml files to generate
summaries like this:
ext4/4k: 430 tests, 1 failures, 43 skipped, 6565 seconds
Failures: generic/388
ext4/1k: 441 tests, 7 failures, 55 skipped, 7985 seconds
Failures: ext4/033 generic/018 generic/383 generic/388 generic/454
generic/475 generic/476
ext4/encrypt: 495 tests, 121 skipped, 4081 seconds
ext4/nojournal: 472 tests, 1 failures, 88 skipped, 4700 seconds
Failures: ext4/301
ext4/ext3conv: 429 tests, 1 failures, 43 skipped, 5965 seconds
Failures: generic/388
ext4/adv: 434 tests, 2 failures, 49 skipped, 5142 seconds
Failures: generic/399 generic/477
ext4/dioread_nolock: 429 tests, 1 failures, 43 skipped, 5870 seconds
Failures: generic/388
ext4/data_journal: 476 tests, 2 failures, 91 skipped, 6832 seconds
Failures: generic/388 generic/475
ext4/bigalloc: 414 tests, 11 failures, 50 skipped, 6963 seconds
Failures: ext4/033 generic/204 generic/219 generic/235 generic/273
generic/388 generic/456 generic/472 generic/494 generic/495
generic/496
ext4/bigalloc_1k: 428 tests, 11 failures, 64 skipped, 5458 seconds
Failures: ext4/033 generic/204 generic/235 generic/273 generic/383
generic/388 generic/454 generic/472 generic/494 generic/495
generic/496
Totals: 3801 tests, 647 skipped, 37 failures, 0 errors, 59147s
> > Tested that started to notrun since baseline?
>
> Its unclear if xunit captures this. Otherwise we have some work to do.
There are software packages that will process xunit XML files, store
them into a database and then generate reports against a defined
baseline. They'll also do fancy graphs, and some of them will show
flakey tests, etc. I haven't had time to investigate them, though,
but if you do find some cool tools to process the xunit files, I'd
definitely be interested.
Cheers,
- Ted
next prev parent reply other threads:[~2018-07-14 0:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-13 2:43 [ANN] oscheck: wrapper for fstests check.sh - tracking and working with baselines Luis R. Chamberlain
2018-07-13 8:39 ` Amir Goldstein
2018-07-13 16:44 ` Luis R. Chamberlain
2018-07-13 17:46 ` Luis R. Chamberlain
2018-07-13 20:40 ` Jeff Mahoney
2018-07-13 20:50 ` Luis R. Chamberlain
2018-07-13 21:03 ` Jeff Mahoney
2018-07-14 0:52 ` Theodore Y. Ts'o [this message]
2018-07-14 6:56 ` Eryu Guan
2018-07-13 20:51 ` Matthew Wilcox
2018-07-13 20:59 ` Luis R. Chamberlain
2018-07-14 22:21 ` Matthew Wilcox
2018-12-03 23:41 ` Luis Chamberlain
2018-12-04 11:01 ` Kent Overstreet
2019-08-16 17:34 ` Luis Chamberlain
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=20180714005207.GF28610@thunk.org \
--to=tytso@mit.edu \
--cc=Alexander.Levin@microsoft.com \
--cc=amir73il@gmail.com \
--cc=fstests@vger.kernel.org \
--cc=jeffm@suse.com \
--cc=levinsasha928@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=valentinrothberg@gmail.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 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).