QA » openQA Project » openQA Tests » qe-yam

riafarov wrote:

Test never worked

Likely the test did work at a time. We also had published s390x Tumbleweed snapshots, e.g. see
https://factory-dashboard.opensuse.org/
listing build 20200413 as the last published one.

But please be aware that the scenario has changed to https://openqa.opensuse.org/tests/latest?arch=s390x&distri=opensuse&flavor=DVD&machine=s390x-zVM-vswitch-l2&test=textmode&version=Tumbleweed as slindomansilla wanted to change the machine name to be in line with what we have on osd.

Additional information: IBM is becoming more engaged and interested in s390x on openSUSE. The user "AdaLovelace" on forum is also employed by IBM and likely she will support the s390x openSUSE release process in the future.

Shouldn't be coredumpctl integrated in a base package? What is required?

AdaLovelace wrote:

Shouldn't be coredumpctl integrated in a base package? What is required?

hm. I don't know if coredumpctl is included in the installation medium here.

Please be aware that the original job in https://openqa.opensuse.org/tests/1464522/modules/await_install/steps/69 stopped on an obvious product issue as even the screen says "Internal error. Please report a bug report with logs". I think this bug report is not yet reported at all. However, without access to logs this will not be very helpful for the YaST development team to help. So either logs are gathered manually with manual reproduction or using the openQA developer mode to try to gather logs manually while the test is running in openQA or the post_fail_hook of the openQA test is fixed or extended to provide that automatically.

@riafarov I am also not sure now as you changed the progress project layout a bit with the newly introduced subproject: I assume a ticket in "qe-yast" and in "Target version" "future" means that you see the issue as in the scope of the team "qe-yast" in general but do not have a current plan to work on this so likely this will not be fixed by "qe-yast" within the next months/years, similar to how we handle tickets in SUSE QE Tools, e.g. for openQA, correct? The "missed opportunity" I see here is that e.g. the team SUSE QE Core might be able to help with this, especially as slindomansilla is very motivated to work on "s390x@openSUSE" but if the ticket is within "qe-yast" he is unlikely to see it. If it would be something like "[qe-yast][qe-core]" in "openQA Tests" than theoretically it has better visibility. I don't know either what's best :)

Any better or other hints that you could offer AdaLovelace what to do?

@okurz Somehow I've missed your last comment. I've assigned this ticket to our team, as we can improve logs collection after failures. Problem here is that seems that network didn't really work (https://openqa.opensuse.org/tests/1464522#step/await_install/121). But we can still put more info to the serial, like last 100 lines of YaST logs, which we already do, but it didn't work here. It's low prio, as issue is not visible anymore and can be reported by reproducing issue manually, as without network it's hard to provide all the info for the investigation.
So for our team scope is to make logs collection more flexible and provide as much info as possible to spend less time on investigation.