Re: kdevops BoF at LSFMM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 8, 2024 at 2:48 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> On Tue, May 7, 2024 at 9:44 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote:
> >
> > Dear LPC session leads,
> >
> > We'd like to gather together and talk about current ongoing
> > developments / changes on kdevops at LSFMM. Those interested in
> > automation on complex workflows with kdevops are also welcomed. This
> > is best addressed informally, but since I see an open slot for at
> > 10:30am for Tuesday, figured I'd check to see if we can snatch it.
>
> The empty slot is there for flexibility of the schedule and also
> wouldn't storage/MM people be interested in kdevops?
>
> I've placed you session instead of the FS lightning talks on Tuesday
> after Leah's FS testing session.
> There are enough slots for FS lightning talks.
>
> There are several empty slots throughout the agenda left for
> flexibility, including the one you mentioned on Tue morning.
> kdevops session is for a very specialized group of developers,
> so if that group is assembled and decides to use an earlier slot
> we can do that on the spot.

kdevops could be *extrememly* useful to understand better (and
to share "best practices" and ideas on testing from various filesystems)

I would be very happy if there were an easy way to do three things
faster/easier:
1) make it easier to run a reasonably large set of fs tests automatically
on checkin of a commit or set of commits (e.g. to an externally visible
github branch) before it goes in linux-next, and a larger set
of test automation that is automatically run on P/Rs (I kick these tests
off semi-manually for cifs.ko and ksmbd.ko today)
2) make it easier as a maintainer to get reports of automated testing of
stable-rc (or automate running of tests against stable-rc by filesystem type
and send failures to the specific fs's mailing list).  Make the tests run
for a particular fs more visible, so maintainers/contributors can note
where important tests are left out against a particular fs
3) make it easier to auto-bisect what commit regressed when a failing test
is spotted
4) make it easier to automatically enable certain fs specific debug
tooling (e.g. eBPF scripts or trace points or log capturing) when a
test fails, or when a test fails - enable tracing and restart tests
5) make it easier to collect log output at the end of each test to
catch "suspicious" things (like network reconnects/timeouts, dmesg
events logged, fs specific stats or debug data that show excessive
failures or slow responses)
6) an easy way to tell if a kdevops run is "suspiciously slow" (ie if a test
or set of tests is more than 20% slower than the baseline test run, it
could indicate a performance regression that needs to be bisected
and identified)

-- 
Thanks,

Steve





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux