action #55805
closedcoordination #56267: [epic][qe-core][functional] openSUSE welcome message is not properly handled
[opensuse][functional][u] test fails in opensuse_welcome - does not have welcome dialog for root logged in
0%
Description
Observation¶
The "opensuse welcome" popup is not shown for root user. This is expected. The module opensuse_welcome should not be scheduled for this scenario.
openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-rootonly@64bit fails in
opensuse_welcome
Acceptance criteria¶
- AC1: The module opensuse_welcome is not scheduled for rootonly scenario
- AC2:
EXCLUDE_MODULES
is not used to fulfill AC1.
Tasks¶
- Create YAML schedule, see https://github.com/os-autoinst/os-autoinst-distri-opensuse/tree/master/schedule/functional
- Link it in functional job group, see https://gitlab.suse.de/qsf-u/qa-sle-functional-userspace/-/blob/master/functional_sle15_jobgroup.yaml
- Remove the
EXCLUDE_MODULES=opensuse_welcome
setting (and update the test suite description)
Further details¶
Always latest result in this scenario: latest
Updated by mlin7442 over 5 years ago
so I think opensuse_welcome module should not applicable if ROOTONLY=1
or this is a product bug ie. why not starts with root, need investigating.
Updated by SLindoMansilla over 5 years ago
- Subject changed from test fails in opensuse_welcome - does not have welcome dialog for root logged in to [opensuse] test fails in opensuse_welcome - does not have welcome dialog for root logged in
- Assignee set to mlin7442
I would say that this is a product bug. Assigning to you since you are investigating the issue.
Updated by SLindoMansilla over 5 years ago
- Priority changed from Normal to High
It seems this doesn't have activity. Please, feel free to unassign if you want U-Team to take over.
Updated by favogt over 5 years ago
The log shows the reason:
Aug 21 17:53:13 install org.opensuse.opensuse_welcome.desktop[2284]: [2284:2284:0821/175313.472485:ERROR:zygote_host_impl_linux.cc(89)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
The embedded chromium used by opensuse-welcome does not support running as root.
Updated by StefanBruens about 5 years ago
So, what should be done here?
As favogt pointed out, openSUSE Welcome will not run for the root user. I would even argue not automatically starting a web browser with "arbitrary" content should be checked for.
So (pseudocode):
if (ROOTONLY) {
check_screen(opensuse-welcome) and die ("openSUSE Welcome should not run for the root user");
} else {
# do as before, i.e. unselect and close
}
Opinions?
Updated by SLindoMansilla about 5 years ago
StefanBruens wrote:
So, what should be done here?
As favogt pointed out, openSUSE Welcome will not run for the root user. I would even argue not automatically starting a web browser with "arbitrary" content should be checked for.
So (pseudocode):
if (ROOTONLY) { check_screen(opensuse-welcome) and die ("openSUSE Welcome should not run for the root user"); } else { # do as before, i.e. unselect and close }
Opinions?
So, as I expected, that needs to be taken in addition to https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8451#discussion_r325169288
So, a function with the handling logic has to be created. Then this function has to be called when needed. Maybe we even can get rid of the opensuse_welcome module, or this module should only call that function.
Updated by StefanBruens about 5 years ago
SLindoMansilla wrote:
So, as I expected, that needs to be taken in addition to https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8451#discussion_r325169288
So, a function with the handling logic has to be created. Then this function has to be called when needed. Maybe we even can get rid of the opensuse_welcome module, or this module should only call that function.
Or just extend opensuse_welcome, no duplication needed.
The big advantage of keeping opensuse_welcome a module instead of a function call is one can actually check whats going on, without 5 levels of functions and nested state to be handled: https://openqa.opensuse.org/tests/1033059/modules/opensuse_welcome/steps/1/src
The wait_boot function in reboot_icewm https://openqa.opensuse.org/tests/1033059 does what the name says - it waits for the (re)boot to complete.
When the boot has completed there is either a plain desktop or the dialog, which should be handled accordingly.
Updated by SLindoMansilla about 5 years ago
StefanBruens wrote:
Or just extend opensuse_welcome, no duplication needed.
The big advantage of keeping opensuse_welcome a module instead of a function call is one can actually check whats going on, without 5 levels of functions and nested state to be handled: https://openqa.opensuse.org/tests/1033059/modules/opensuse_welcome/steps/1/src
This ticket was open to this kind of implementation.
Your PR made me think it is not possible. So, let's extend the opensuse_welcome module so that your PR is not needed. Otherwise you are not argumenting in favor of your PR.
If your PR is still necessary and the opensuse_welcome module cannot be extended to avoid the changes on your PR, then I still beg for a function that is used in the places your PR addresses and in the opensuse_welcome module.
The wait_boot function in reboot_icewm https://openqa.opensuse.org/tests/1033059 does what the name says - it waits for the (re)boot to complete.
When the boot has completed there is either a plain desktop or the dialog, which should be handled accordingly.
You are basically saying that I am right. A proper function that does what is expected is better when we have to call this logic in different modules and scenarios.
The wait_boot function was created after the pain of having several modules in several places for several products implementing several ways of rebooting, waiting for boot. So, even if that function exists, it is a pain to change the code without breaking another module in another scenario from another SUSE product. So, even if the function does what is expected, it is not used in all places.
Example of horror story: https://progress.opensuse.org/issues/38423
Updated by okurz about 5 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: rootonly
https://openqa.opensuse.org/tests/1045686
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by okurz about 5 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: rootonly
https://openqa.opensuse.org/tests/1058820
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by okurz about 5 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: rootonly
https://openqa.opensuse.org/tests/1071859
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by SLindoMansilla about 5 years ago
- Description updated (diff)
- Assignee deleted (
mlin7442)
Two months of inactivity after the reminder. U-Team will take over ;)
Updated by SLindoMansilla about 5 years ago
- Follows action #55661: [opensuse][u] test fails in several modules after booting and login - "openSUSE Welcome" not handled (WAS: test fails in first_boot) added
Updated by SLindoMansilla about 5 years ago
- Status changed from New to Blocked
Tracking.
By now, I have added EXCLUDE_MODULES=opensuse_welcome to the test suite rootonly on https://openqa.opensuse.org/admin/test_suites
Updated by SLindoMansilla almost 5 years ago
- Status changed from Blocked to New
Updated by SLindoMansilla over 4 years ago
- Subject changed from [opensuse] test fails in opensuse_welcome - does not have welcome dialog for root logged in to [opensuse][functional][u] test fails in opensuse_welcome - does not have welcome dialog for root logged in
- Create YAML schedule
- Remove the
EXCLUDE_MODULES
setting
Updated by SLindoMansilla over 4 years ago
- Status changed from New to Workable
- Target version set to Milestone 30
- Estimated time set to 42.00 h
Updated by zluo over 4 years ago
- Status changed from Workable to In Progress
- Assignee set to zluo
take over
Updated by zluo over 4 years ago
this can be done like my PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10028
add yaml schedule for rootonly scenairo and remove EXCLUDE_MODULES item.
Updated by zluo over 4 years ago
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10294 created.
will remove EXCLUDE_MODULES=opensuse_welcome after merge.
Updated by zluo over 4 years ago
PR merged now, rootonly test suite updated now at https://openqa.opensuse.org/admin/test_suites
check this later on O3 for this change.
Updated by zluo over 4 years ago
- Status changed from In Progress to Resolved
https://openqa.opensuse.org/tests/1273764: resolved now.