All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: lsf-pc@lists.linux-foundation.org
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	linux-fsdevel@vger.kernel.org, Eryu Guan <guaneryu@gmail.com>,
	Jan Kara <jack@suse.cz>, Mel Gorman <mgorman@suse.de>
Subject: [LSF/MM/BPF TOPIC] Increasing automation of filesystem testing with kdevops
Date: Thu, 13 Feb 2020 19:35:34 +0000	[thread overview]
Message-ID: <20200213193534.GP11244@42.do-not-panic.com> (raw)

Ever since I've taken a dive into filesystems I've been trying to
further automate filesytem setup / testing / collection of results.
I had looked at xfstests-bld [0] but was not happy with it being cloud
specific to Google Compute Engine, and so I have been shopping around
for technology / tooling which would be cloud agnostic / virtualization
agnostic.

At the last LSFMM in Puerto Rico the project oscheck [1] was mentioned a
few times as a mechanism as to how to help get set up fast with fstests,
however *full* automation to include running the tests, processing
results, and updating a baseline was really part of the final plan.
I had not completed the work yet by LSFM Puerto Rico, so could not
talk about the work. The majority of the effort is now complete
and is part of kdevops [2], now a more generic framework to help automated
kernel development testing. I've written a tiny bit about it [3]. Due to
the nature of LSFMM I don't want to present the work, unless folks
really want me to, so would rather have a discussion over technologies
used, pain points to consider, some future ideas, and see what others
are doing. May be worth just as a simple BoF.

So let me start in summary style with some of these on my end.

Technologies used:

  * vagrant / terraform
  * ansible

Pain points:

  * What fstests doesn't cover, or an auto-chinner needed:
    - fsmark regressions, for instance:
      https://lkml.org/lkml/2013/9/10/46
  * vagrant-libvirt is not yet part of upstream vagrant but neeed
    for use with KVM
  * Reliance on only one party (Hashi Corp) for the tooling, even though
    its all open source
  * Vagrant's dependency on ruby and several ruby gems
  * terraform's reliance on tons of go modules
  * "Enterpise Linux" considerations for all the above

Future ideas:

  * Using 9pfs for sharing git trees
  * Does xunit suffice?
  * Evaluating which tests can be folded under kunit
  * Evaluating running one test per container so to fully parallelize testing

[0] https://git.kernel.org/pub/scm/fs/ext2/xfstests-bld.git
[1] https://github.com/mcgrof/oscheck
[2] https://github.com/mcgrof/kdevops
[3] https://people.kernel.org/mcgrof/kdevops-a-devops-framework-for-linux-kernel-development

  Luis

             reply	other threads:[~2020-02-13 19:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-13 19:35 Luis Chamberlain [this message]
2020-03-07  3:18 ` [LSF/MM/BPF TOPIC] Increasing automation of filesystem testing with kdevops Steve French

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=20200213193534.GP11244@42.do-not-panic.com \
    --to=mcgrof@kernel.org \
    --cc=guaneryu@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=mgorman@suse.de \
    /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.