Project

General

Profile

Actions

action #9498

closed

[functional]Advanced Handling of Dependency issues

Added by RBrownSUSE over 8 years ago. Updated almost 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Enhancement to existing tests
Start date:
2015-11-11
Due date:
% Done:

70%

Estimated time:
Difficulty:

Description

User story

As a developer, I want to go through with an installation of a test product, in order to be able to check the reliability and functionality of the system later

acceptance criteria

  • AC1: report soft failure if dependency issue appears during installation
  • AC2: solve dependency issues: workaround or break dependency

tasks

  • when dependency issue appears during installation, a soft failure will be reported
  • after the soft failure is reported, depending on which parameter the SUT got, dependency issues can be solved in two ways: workaround - not to install selected modules, or break dependency and install the modules
  • solve multi and chained dependency issues until the SUT can continue with installation

Checklist

  • SLE
  • Leap
  • TW
Actions #1

Updated by RBrownSUSE over 8 years ago

  • Checklist item changed from to [ ] SLE, [ ] Leap, [ ] TW
  • Target version deleted (154)
Actions #2

Updated by maritawerner over 7 years ago

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

Actions #3

Updated by RBrownSUSE over 7 years ago

Not done, cannot be closed

Actions #4

Updated by RBrownSUSE over 7 years ago

  • Subject changed from Advanced Handling of Dependency issues to [functiona]Advanced Handling of Dependency issues
  • Assignee deleted (RBrownSUSE)
Actions #5

Updated by RBrownSUSE over 7 years ago

  • Subject changed from [functiona]Advanced Handling of Dependency issues to [functional]Advanced Handling of Dependency issues
Actions #6

Updated by Anonymous about 7 years ago

  • Assignee set to Anonymous
Actions #7

Updated by Anonymous about 7 years ago

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 {

Actions #8

Updated by RBrownSUSE about 7 years ago

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.

Actions #9

Updated by Anonymous about 7 years ago

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?

Actions #10

Updated by RBrownSUSE about 7 years ago

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.

Actions #11

Updated by Anonymous about 7 years ago

  • Target version set to Milestone 10
Actions #12

Updated by jorauch about 7 years ago

  • Checklist item changed from to [x] Leap
Actions #13

Updated by jorauch about 7 years ago

  • Checklist item changed from to [ ] Leap
Actions #15

Updated by Anonymous about 7 years ago

  • Description updated (diff)
Actions #16

Updated by Anonymous about 7 years ago

  • Description updated (diff)
Actions #17

Updated by Anonymous about 7 years ago

  • Description updated (diff)
Actions #18

Updated by Anonymous almost 7 years ago

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.

Actions #19

Updated by Anonymous almost 7 years ago

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.

Actions #20

Updated by Anonymous almost 7 years ago

  • Status changed from In Progress to Feedback
Actions #21

Updated by okurz almost 7 years ago

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

Actions #22

Updated by Anonymous almost 7 years ago

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

Actions #23

Updated by okurz almost 7 years ago

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?

Actions #24

Updated by Anonymous almost 7 years ago

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.

Actions #25

Updated by okurz almost 7 years ago

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');

Actions #27

Updated by Anonymous almost 7 years ago

  • Status changed from Feedback to In Progress
Actions #28

Updated by Anonymous almost 7 years ago

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

Actions #29

Updated by Anonymous almost 7 years ago

  • Status changed from In Progress to Resolved
Actions #30

Updated by okurz almost 7 years ago

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

Actions

Also available in: Atom PDF