linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: Sasha Levin <sashal@kernel.org>,
	Amir Goldstein <amir73il@gmail.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	lsf-pc <lsf-pc@lists.linux-foundation.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Jan Kara <jack@suse.cz>,
	"Darrick J. Wong" <darrick.wong@oracle.com>,
	Josef Bacik <josef@toxicpanda.com>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [LSF/MM TOPIC] FS, MM, and stable trees
Date: Fri, 11 Mar 2022 17:04:37 -0500	[thread overview]
Message-ID: <YivHdetTMVW260df@mit.edu> (raw)
In-Reply-To: <Yiu2mRwguHhbVpLJ@bombadil.infradead.org>

On Fri, Mar 11, 2022 at 12:52:41PM -0800, Luis Chamberlain wrote:
> 
> The only way to move forward with enabling more automation for kernel
> code integration is through better and improved kernel test automation.
> And it is *exactly* why I've been working so hard on that problem.

I think we're on the same page here.

> Also let's recall that just because you have your own test framework
> it does not mean we could not benefit from others testing our
> filesystems on their own silly hardware at home as well. Yes tons
> of projects can be used which wrap fstests...

No argument from me!  I'm strongly in favor of diversity in test
framework automation as well as test environments.

In particular, I think there are some valuable things we can learn
from each other, in terms of cross polination in terms of features and
as well as feedback about how easy it is to use a particular test
framework.

For example: README.md doesn't say anything about running make as root
when running "make" as kdevops.  At least, I *think* this is why
running make as kdevops failed:

fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["/usr/sbin/apparmor_status", "--enabled"], "delta": "0:00:00.001426", "end": "2022-03-11 16:23:11.769658", "failed_when_result": true, "rc": 0, "start": "2022-03-11 16:23:11.768232", "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}

(I do have apparmor installed, but it's currently not enabled.  I
haven't done more experimentation since I'm a bit scared of running
"make XXX" as root for any package I randomly download from the net,
so I haven't explored trying to use kdevops, at least not until I set
up a sandboxed VM.  :-)

Including the Debian package names that should be installed would also
be helpful in kdevops/doc/requirements.md.  That's not a problem for
the experienced Debian developer, but one of my personal goals for
kvm-xfstests and gce-xfstests is to allow a random graduate student
who has presented some research file system like Betrfs at the Usenix
FAST conference to be able to easily run fstests.  And it sounds like
you have similar goals of "enabling the average user to also easily
run tests".


> but I never found one
> as easy to use as compiling the kernel and running a few make commands.

I've actually done a lot of work to optimize developer velocity using
my test framework.  So for example:

kvm-xfstests install-kconfig    # set up a kernel Kconfig suitable for kvm-xfstests and gce-xfstests
make
kvm-xfstests smoke     # boot the test appliance VM, using the kernel that was just built

And a user can test a particular stable kernel using a single command
line (this will checkout a particular kernel, and build it on a build
VM, and then launch tests in parallel on a dozen or so VM's):

gce-xfstests ltm -c ext4/all -g auto --repo stable.git --commit v5.15.28

... or if we want to bisect a particular test failure, we might do
something like this:

gce-xfstests ltm -c ext4 generic/361 --bisect-good v5.15 --bisect-bad v5.16

... or I can establish a watcher that will automatically build a git
tree when a branch on a git tree changes:

gce-xfstests ltm -c ext4/4k -g auto --repo next.git --watch master

Granted, this only works on GCE --- but feel free to take these ideas
and integrate them into kdevops if you feel inspired to do so.  :-)

> There is the concept of results too and a possible way to share things..
> but this is getting a bit off topic and I don't want to bore people more.

This would be worth chatting about, perhaps at LSF/MM.  xfstests
already supports junit results files; we could convert it to TAP
format, but junit has more functionality, so perhaps the right
approach is to have tools that can support both TAP and junit?  What
about some way to establish interchange of test artifacts?  i.e.,
saving the kernel logs, and the generic/NNN.full and
generic/NNN.out.bad files?

I have a large library of these test results and test artifacts, and
perhaps others would find it useful if we had a way sharing test
results between developers, especially we have multiple test
infrastructures that might be running ext4, f2fs, and xfs tests?

Cheers,

						- Ted

  reply	other threads:[~2022-03-11 22:42 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-12 17:00 [LSF/MM TOPIC] FS, MM, and stable trees Sasha Levin
2019-02-12 21:32 ` Steve French
2019-02-13  7:20   ` Amir Goldstein
2019-02-13  7:37     ` Greg KH
2019-02-13  9:01       ` Amir Goldstein
2019-02-13  9:18         ` Greg KH
2019-02-13 19:25           ` Sasha Levin
2019-02-13 19:52             ` Greg KH
2019-02-13 20:14               ` James Bottomley
2019-02-15  1:50                 ` Sasha Levin
2019-02-15  2:48                   ` James Bottomley
2019-02-16 18:28                     ` Theodore Y. Ts'o
2019-02-21 15:34                       ` Luis Chamberlain
2019-02-21 18:52                         ` Theodore Y. Ts'o
2019-03-20  3:46               ` Jon Masters
2019-03-20  5:06                 ` Greg KH
2019-03-20  6:14                   ` Jon Masters
2019-03-20  6:28                     ` Greg KH
2019-03-20  6:32                       ` Jon Masters
2022-03-08  9:32 ` Amir Goldstein
2022-03-08 10:08   ` Greg KH
2022-03-08 11:04     ` Amir Goldstein
2022-03-08 15:42       ` Luis Chamberlain
2022-03-08 19:06       ` Sasha Levin
2022-03-09 18:57         ` Luis Chamberlain
2022-03-11  5:23           ` Theodore Ts'o
2022-03-11 12:00             ` Jan Kara
2022-03-11 20:52             ` Luis Chamberlain
2022-03-11 22:04               ` Theodore Ts'o [this message]
2022-03-11 22:36                 ` Luis Chamberlain
2022-04-27 18:58                 ` Amir Goldstein
2022-05-01 16:25                   ` Luis Chamberlain
2022-03-10 23:59         ` Steve French
2022-03-11  0:36           ` Chuck Lever III
2022-03-11 20:54             ` Luis Chamberlain
2022-03-08 16:40     ` Theodore Ts'o
2022-03-08 17:16       ` Amir Goldstein
2022-03-09  0:43       ` Dave Chinner
2022-03-09 18:41       ` Luis Chamberlain
2022-03-09 18:49         ` Josef Bacik
2022-03-09 19:00           ` Luis Chamberlain
2022-03-09 21:19             ` Josef Bacik
2022-03-10  1:28               ` Luis Chamberlain
2022-03-10 18:51                 ` Josef Bacik
2022-03-10 22:41                   ` Luis Chamberlain
2022-03-11 12:09                     ` Jan Kara
2022-03-11 18:32                       ` Luis Chamberlain
2022-03-12  2:07                   ` Luis Chamberlain
2022-03-14 22:45                     ` btrfs profiles to test was: (Re: [LSF/MM TOPIC] FS, MM, and stable trees) Luis Chamberlain
2022-03-15 14:23                       ` Josef Bacik
2022-03-15 17:42                         ` Luis Chamberlain
2022-03-29 20:24       ` [LSF/MM TOPIC] FS, MM, and stable trees Amir Goldstein
2022-04-10 15:11         ` Amir Goldstein
2022-03-08 10:54   ` Jan Kara
2022-03-09  0:02   ` Dave Chinner

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=YivHdetTMVW260df@mit.edu \
    --to=tytso@mit.edu \
    --cc=amir73il@gmail.com \
    --cc=darrick.wong@oracle.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jack@suse.cz \
    --cc=josef@toxicpanda.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=mcgrof@kernel.org \
    --cc=sashal@kernel.org \
    --cc=willy@infradead.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).