jankara

xfstests is rather comprehensive filesystem testing framework used for functional filesystem testing. The aim of this project is to integrate xfstests with our qa_automation framework so that xfstests can be run in it and results are automatically processed and stored in qadb.

Retty is a tool for changing stdin,stdout,stderr of a running process (http://pasky.or.cz/dev/retty/) which may be handy if you want to attach to a process running e.g. from a died ssh session, changing running process to run from under screen(1) etc.. Currently it doesn't work for 64-bit systems and it doesn't handle changing of a controlling tty of a process (which may be possible using setsid() and opening a new tty). The aim of this project it to fix the above deficiencies and package the tool in OBS.

Currently, each filesystem developer does his fstests runs (a testsuite for regression-testing of filesystems) on his dedicated test machine, on Orthos machine, ... This not only means duplication of efforts to automate this testing but also leads to inefficient use of resources (sometimes the test machine is just idle, sometimes you would need more tests to run in parallel to speed up development). The goal of this effort is to use SUSE Engineering Cloud to implement fire-and-forget fstests runs where you specify kernel to test (fetched from git tree or so), fstests configs to run, and then just pick up test results later on...

Diagnosing issues with stalling desktop application (or a whole desktop environment) is difficult these days as the application often requires multiple processes interconnected with sockets, pipes, futexes, etc. to work and often it is not clear which process is the one responsible for blocking the whole ecosystem. The idea of this project is to write a tool that gathers information about processes in the system and for each process that is sleeping display the resource (file, socket, futex) it is waiting on as well as the process that is likely responsible for unblocking (feeding pipe, sending data to socket, unlock futex, ...). Once the information is gathered, we can also plot it for graphical displaying with tools like graphviz.

Bisection is a well known method of localizing which commit caused a regression in a code repository. git-bisect is a particularly used tool for this problem in git repositories. However it is often the case that the failure is probabilistic in nature - either because we don't have a reliable reproducer of the failure and thus not reproducing a problem on a particular commit does not mean the problem is not still present there, or because of inherent variability of e.g. performance regressions. Bisection for such failures is problematic as it takes only one false result for the bisection to end up in an unrelated part of code history. So in these cases we usually have to heavily extend runtime of a reproducer or do multiple test runs or multiple bisection runs to minimize a chance of error.