Description of problem: When investigating failures (or unexpected passes) one doesn't have enough information about the environment the test. It will create a lot of output, so we need to figure where/how it should submit the data. a) installed rpms and its version PACKAGE not enough - think about all required (implied stuff) as grep, lsof, procps or (indirect) test dependencies as fonts, Xvfb. Packages are installed in kickstart, but usually upgrade to latest available versions in repositories is done - it is huge pain to process all logs from the test to kickstart to see what is installed and in which version. b) cpu load / disk|swap usage It could help to decide whether machine was under load or the program under test is to blame. c) environment variables Some can modify how system works, e.g. malloc Or modify what the test does.
+1 to storing all rpms (and their NVRs) and the environment variabls at least for each task.
The question is when and how to do it, and where to store it. It might be slow operation (rpm -qa) - I know it from test inspector. May be it could be run in the background not to block test itself. And also it is questionable whether to run it automatically in rlJournalStart or whether to create a dedicated function. If we decide to run it automatically I would propose following solution: 1) run it in background somewhere in rlJournalStart 2) wait within rlJournalEnd for finishing the job 3) the output should be store in journal if we hook it to journal functions There should be also some timeout for the job not to let the test stuck on it. Also it might be destructive for tests which somehow handle background jobs so it would be good to use rlDeamonize proposed in bz835947. Also by the background job we would be able to gather some other statistics like CPU load. All this should be done using hooks to allow future extending.
wow, that seems complicated. It 'rpm -qa' really that slow?
Depends on disk speed and number of packages. On my Fedora with 2500 packages on SSD it takes over 3 seconds for the first time and then over 1 second. I have also tried all ITP and SS a it took at best 1.2s and at worst 65s. So I would not recommend to make it as blocking operation widely.
(In reply to Dalibor Pospíšil from comment #4) > ...at worst 65s. that's pretty bad. ok then, foreground 'rpm -qa' should be off the table. thanks for testing it.
On the other hand running rpm -qa in the background could cause problems with timing in test. If it is the case of slow HDD it could slow down whole machine so the test starts to fail due to slow response. So I really do not know what way to go.
Well, Use Case is to know the state of the system before the test was run. rpm -qa looked like most direct way. How about copying relevant file from /var/lib/rpm? It might be few hundred of MB. Or one could trust that TESTOUT.log will contain rpm/yum outputs and process it semi-automatically (yeah, crazy idea).