All of lore.kernel.org
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	Sasha Levin <sashal@kernel.org>,
	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: Wed, 27 Apr 2022 21:58:53 +0300	[thread overview]
Message-ID: <CAOQ4uxg+5XUxD19Zh_WoTjVc+yU-mjjCrgWN+85=oZe=pSKO2Q@mail.gmail.com> (raw)
In-Reply-To: <YivHdetTMVW260df@mit.edu>

On Sat, Mar 12, 2022 at 12:04 AM Theodore Ts'o <tytso@mit.edu> wrote:
>
> 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?
>

Hi Ted,

I penciled a session on "Challenges with running fstests" in the
agenda.

I was hoping that you and Luis could co-lead this session and
present the progress both of you made with your test frameworks.

Thanks,
Amir.

  parent reply	other threads:[~2022-04-27 19:07 UTC|newest]

Thread overview: 60+ 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-12 21:32   ` Steve French
2019-02-13  7:20   ` Amir Goldstein
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: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-13 20:14                 ` James Bottomley
2019-02-15  1:50                 ` Sasha Levin
2019-02-15  2:48                   ` James Bottomley
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
2022-03-11 22:36                 ` Luis Chamberlain
2022-04-27 18:58                 ` Amir Goldstein [this message]
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='CAOQ4uxg+5XUxD19Zh_WoTjVc+yU-mjjCrgWN+85=oZe=pSKO2Q@mail.gmail.com' \
    --to=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=tytso@mit.edu \
    --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 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.