action #124646


[ALP] consider using y2log-util for any yast tests

Added by lkocman over 1 year ago. Updated 3 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Can we please use this tool for any yast2 relevant tests for ALP?

YaST team is demanding it as in many cases we don't have adequate logs

To my knowledge this is set of scripts, not really packaged.

Thank you

Related issues 1 (1 open0 closed)

Related to openQA Tests - coordination #68794: [qe-core][functional][epic] rework postfail hooksBlockedszarate2020-03-31

Actions #1

Updated by lkocman over 1 year ago

  • Description updated (diff)
Actions #2

Updated by lkocman over 1 year ago

Trigger was a conversation with Stefan Hundhammer

Actions #3

Updated by maritawerner over 1 year ago

  • Project changed from openQA Tests to 175

I move it to the qam-qasle-coordination project, so that it can be discussed in the QA sync call.

Actions #4

Updated by JERiveraMoya about 1 year ago

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 (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.

Actions #5

Updated by JERiveraMoya about 1 year ago

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, 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.

Actions #6

Updated by JERiveraMoya about 1 year ago

  • Assignee set to JERiveraMoya
Actions #7

Updated by jstehlik about 1 year ago

  • Due date set to 2023-03-15
  • Assignee changed from JERiveraMoya to JRivrain

due date set for clarification

Actions #8

Updated by JERiveraMoya about 1 year ago

  • Assignee changed from JRivrain to JERiveraMoya

Answer from Stefan:
"YaST is demanding" it is not what I meant to say back then
I was just giving him a hint that this thing exists
it might be useful if a test is just about one single YaST call
and the y2logs still contain everything starting with the installation
I actually meant for you guys to have a look at the tools and experiment
and then decide if they are useful to you, and how"

Actions #9

Updated by szarate about 1 year ago

Actions #10

Updated by jstehlik about 1 year ago

Felix: log collection can be controlled by a parameter

Actions #11

Updated by JERiveraMoya about 1 year ago

  • Project changed from 175 to qe-yam
  • Due date deleted (2023-03-15)
  • Assignee deleted (JERiveraMoya)
  • Priority changed from Normal to Low

As we have already discussed this task multiple times and I keep getting reminders in the mail, removing due date and assignee as the main problem is the the visualization of the log retrieval in openQA, the first red box is the valid one, after that if there are other errors found there might be or there might not be related and suppressing logs doesn't help because you might want them anyway.

I moved to qe-yam subproject to take a look in the future.
From our side this would be just an investigation task if those script could do any good. I will keep tag [ALP] for now but it might be applicable for any product.
Please comment if disagree.

Actions #12

Updated by JERiveraMoya 3 months ago

  • Status changed from New to Rejected

Backlog clean-up.


Also available in: Atom PDF