action #35959
closed
coordination #34333: [functional][y][epic] More test scenarios covering installation on existing partition layouts
[sle][functional][y][s390x][medium] Add tests for s390x to test on "existing sle on dasd" and explicitly test the DASD formatting during installation
Added by mgriessmeier almost 6 years ago.
Updated over 2 years ago.
Target version:
SUSE QA - Milestone 17
Description
User Story¶
Right now we format the DASD on which the system is going to be installed before we start the installation.
Except in one case (ext4), where we set FORMAT_DASD_YAST to trigger the formatting during installation
This ticket is about adding two new testcases to be more explicit on this
This PR is about being able to set different values for FORMAT_DASD_YAST -> https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/4978
Acceptance Criteria¶
AC1: FORMAT_DASD_YAST setting is not used in existing ext4 testsuite to be more consistent compared to other installation scenarios
AC2: explicit testsuite formats DASD during installation is enabled for SLE12 and SLE15
AC3: explicit testsuite which will not format the DASD at all for SLE12 and SLE15
Suggestion¶
We might need to find a better naming for this variable and values, e.g. FORMAT_DASD_YAST may have 3 possible values for each of scenarios defined.
careful, the acceptance criteria read like "suggestions". Please rephrase description
- Description updated (diff)
- Status changed from New to Workable
- Subject changed from [sle][functional][y][s390x] Add tests for s390x to test on "existing sle on dasd" and explicitly test the DASD formatting during installation to [sle][functional][y][s390x][medium] Add tests for s390x to test on "existing sle on dasd" and explicitly test the DASD formatting during installation
- Due date changed from 2018-05-22 to 2018-06-05
PR reverted, need to analyze.
- Parent task set to #34333
- Status changed from Workable to Feedback
Current obstacles: FULL_LVM_ENCRYPT variable is required to handle encrypted boot partition. Additionally, HDD_1 setting must be undef in child job, as no qcow is created and published on zVM. New test suite will fix the issue, as we anyway need special WORKER_CLASS.
- Due date changed from 2018-06-05 to 2018-06-19
- Target version changed from Milestone 16 to Milestone 17
waiting for PR to be merged to reuse cryptlvm test suite for zVM as well.
Latest finding is that it's not possible to guarantee that 2 test suites will be executed one after another if there is no dedicated worked which is not used for anything else. Considering implementing part where we partition disk and encrypt partitions to see that it works.
- Status changed from Feedback to Resolved
- Target version changed from Milestone 17 to Milestone 17
- Due date deleted (
2018-06-19)
Also available in: Atom
PDF