QA (public) » openQA Project (public) » openQA Tests (public)

Richard, I think that is done? So we can close that?

Not done, cannot be closed

I've checked related code, and in most of case it will record soft failure when a dependency issue appears, only in the function check_and_record_dependency_problems it dies if the parameter WORKAROUND_DEPS is not set. And this function is only called in installation_overview.pm and installation_overview_before.pm. We can let it here also record soft failure if necessary, however I think to this ticket it is actually almost done. What is your opinion?

lib/y2logsstep.pm: if (get_var("WORKAROUND_DEPS")) {
lib/y2logsstep.pm- $self->record_dependency_issues;
tests/installation/select_patterns_and_packages.pm: if (check_screen('dependancy-issue', 10) && get_var("WORKAROUND_DEPS")) {
tests/installation/select_patterns_and_packages.pm- $self->record_dependency_issues;
tests/installation/zdup.pm: if (get_var("WORKAROUND_DEPS")) {
tests/installation/zdup.pm- record_soft_failure 'workaround dependencies';
lib/y2logsstep.pm-# to workaround dep issues
lib/y2logsstep.pm:sub record_dependency_issues {
lib/y2logsstep.pm:# check for dependency issues, if found, drill down to software selection, take a screenshot, then die
lib/y2logsstep.pm:sub check_and_record_dependency_problems {

To clarify - we have some basic dependency handling in the tests already, but this typically can only handle simple dependency problems, such as a product that cannot be installed because of a single dependency problem.

As far as I'm aware, it does not handle the following situations

1) Multiple dependency problems happening at once (eg. "Product Cannot be Installed because of FOO && Product Cannot Be Installed because of BAR")

2) Chained dependency problems (eg. "Ignoring dependency problem FOO leads to a new dependency problem BAR")

This 'advanced handling' should be able to handle the above scenarios and any other similarly complicated dependency warning and work around those problems in a more complicated way.

I think this new feature should use the same WORKAROUND_DEPS variable to enable it as the current version.

OK, the current solution deals with simple cases. I've checked in the needle repository, and there are two needles in this case: dependancy-issue(here even a type) and inst-overview-dep-warning. According to what you wrote, an easy approach would be to add some more needles, e.g. multi-dep-issue and chained-dep-issue, and then do the similar check as what is done now.

What do you think?

that might be a valid approach but I think it will be hard to make an accurate needle that detects when there is multiple dependency problems without also needling specific package names and details of the dependency that you do not want in the needle

I think the better approach would likely be a loop that repeatedly detects whether or not there is a dependency problem, and tries its best to solve them one at a time, until remaining problematic dependencies is zero.

PR created: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3252

PR submitted. AC1 and AC2 fulfilled.
AC1: report soft failure if dependency issue appears during installation
AC2: solve dependency issues: workaround or break dependency by explicitly adding parameter WORKAROUND_DEPS=1 or BREAK_DEPS=1.

Added parameter BREAK_DEPS=1 to scenario migration_offline_sled11_sp4_allpatterns_sdk, btrfs. Added parameter WORKAROUND_DEPS=1 to scenario package-dependency. btrfs has already parameter WORKAROUND_DEPS=1. Now check the test results at openqa.suse.de.

would it harm to specify both? riafarov deleted the special settings on the btrfs test suite and put BREAK_DEPS on the medium where - I guess it was rbrown - WORKAROUND_DEPS was already in place

No, you can only specify one. Each parameter points to different workflow.

Well, apparently I could specify both :-) So what do you suggest? OTOH how about making sure at least one scenario within o3 is using each of these variables?

I have added parameter BREAK_DEPS=1 to scenario migration_offline_sled11_sp4_allpatterns_sdk, btrfs, and parameter WORKAROUND_DEPS=1 to scenario package-dependency.

You mentioned both can be specified, I actually met that problem doing test for btrfs, as it picks up the default parameter(was added by rbrown or someone) all the time no matter what I wrote in the command line. But I have written the parameters to scenarios (last week already, however the tests were not triggered because we didn't have new build). A user doesn't need to write the parameter manually, so it shouldn't happen so easily that both are set to 1.

Sure. I recommend to prevent the user from specifying both parameters by "dying" the test with a helpful message, e.g. die 'BREAK_DEPS and WORKAROUND_DEPS must not be specified together' if get_var('BREAK_DEPS') and get_var('WORKAROUND_DEPS');

Verification runs are:
https://openqa.suse.de/tests/1116285
https://openqa.suse.de/tests/1116280
https://openqa.suse.de/tests/1116279

Verification testrun (with parameter BREAK_DEPS=1) finished installation:
https://openqa.suse.de/tests/1122330

ok, I removed the comment _COMMENT within https://openqa.suse.de/admin/products