QA » openQA Project » openQA Tests » qe-yam

Trigger was a conversation with Stefan Hundhammer

Those are some set of scripts and as described in the repo without warranty to work.
These scripts are to manipulate logs and might be handy for the tester to know them and do some filtering, but save_y2logs is the tool packaged and used in SLE which give you all the information. The same tool will be used to retrieve logs when using YaST in Containers in ALP.
For D-Installer the web application has an option in the hamburger panel to get the logs (it is using save_y2logs) under the hood.
Instead of these scripts for the tester it might even be more useful to use https://github.com/lslezak/ylogviewer2 (I think it is also plan to integrate it with the D-Installer).
The openQA job referenced in the bug has adequate logs created with save_y2logs, the *.tar.bz2 files generated by this tool should be enough for developers, merging the content of the individual part of YaST logs in single file or doing other operations, I don't think it would needed by the automation, or please let me know if I missing something about the motivation.
What happens sometimes is that the automation missed to retrieve YaST logs, but that is a problem that need to be deal with case by case, there is a complex hierarchy of Perl classes that are doing that and when it fails in one point, sporadically we don't have logs there and we need to gather them manually.. I remember QE Core has some ticket related with improvements in this area afir.

I checked with Stefan about this and I understand a bit better what the his tool does, but I haven't tried myself yet.
What he called log noise in the bug is the way we retrieve logs in openQA for YaST, we do a bunch of checks after the test has failed.
So the error is with this validation https://openqa.opensuse.org/tests/3114802#step/yast2_ntpclient/21, first red box, should be a test assertion, but it looks like a command that just failed, but that is how openQA works, specially for very old test module like this one, if you design the test module better, it might be more clear what is going on. Later there is the log retrieval that might be confusing because it might not correlate with the bug because it seems that has found some other errors in the logs unrelated.
Perhaps after an assertion in a test, we should just upload the logs and not show that noise and when the test fail navigating somewhere then it might make sense to show the logs, because some UI component probably has failed. But we don't have that distinction in the framework about assertions and normal actions.
We are actually planning to create some small assertion library to include screenshots when we use libyui-rest-api and we could take this into account.

I will assign this ticket to me to not forget, but need to figure out what is the motivation, I need to ask them why they are 'demanding' it, I don't make sense to that part as once there are logs, they go straightforward to them and know what is happening, but if we got confused by openQA output...that is another story.

Felix: log collection can be controlled by a parameter