action #45152
closed[sle][functional][y][rt] extend test coverage of RT installation
0%
Description
I would like to initiate a discussion regarding possible modules to use in installation validation.
Let me propose the bear minimum modules, which might be useful and already exists in our test directory.
- console/firewall_enabled
- console/aplay
- console/btrfs_autocompletition
- console/glibc_sanity
- console/gpt_ptable
- console/gpg
- console/journalctl
- console/kdump_and_crash
- console/rsync
- console/http_srv
- console/sshd
- console/sysctl
- console/sysstat
- console/cron
- console/yast2_lan
- console/yast2_bootloader
- console/yast2_i
- console/yast2_clone_system
- toolchain/gcc_compilation
- toolchain/gcc_fortran_compilation
- x11/firefox
- x11/wireshark
- x11/yast2_snapper
- x11/yast2_hostnames
- x11/yast2_firewall
- console/consoletest_setup
- console/zypper.ref
- console/zypper.lr
- rt/kmp_modules
- rt/rt_devel_packages
- rt/rt_is_realtime
- rt/rt_peak_pci
- rt/rt_preempt_test
- console/hostname
Acceptance criteria¶
- List of modules to be used is identified
- The identified set of modules is enabled in the test suite for RT product
Suggestions¶
We could use new scheduling mechanism not to deal with main.pm complexity.
Updated by mloviska about 6 years ago
- Category set to Enhancement to existing tests
Updated by okurz about 6 years ago
- Category changed from Enhancement to existing tests to New test
- Target version set to Milestone 23
Hi Martin, I will change the category to "New test" as we use that commonly for any extension of test coverage, regardless if we would actually need to add any new test modules, scenarios, etc. See https://progress.opensuse.org/projects/openqatests/wiki#ticket-workflow for details. OK for you?
I think this is a good idea and thanks for the detailed list. I would go with #45149 first and then this one so maybe something for M23 assuming that M22 will not have much non-Christmas-vacation time left :)
Updated by okurz almost 6 years ago
- Status changed from New to Feedback
- Assignee set to okurz
waiting for clarification (email)
Updated by mloviska almost 6 years ago
- Related to action #45149: [sle][functional][y][rt][bsc#1119412] validate booted kernel (or workaround for kernel selection) added
Updated by mloviska almost 6 years ago
- Due date changed from 2018-12-26 to 2019-02-26
Updated by riafarov almost 6 years ago
- Status changed from Feedback to Blocked
Let's resolve #46874 first, as anyway image is not yet created.
Updated by riafarov almost 6 years ago
- Blocked by action #46874: [sle][functional][rt][y] - replace rt_preempt_test by rt-tests ( cyclictest & hackbench ) added
Updated by okurz almost 6 years ago
- Due date changed from 2019-02-26 to 2019-03-12
- Status changed from Blocked to New
- Assignee deleted (
okurz) - Priority changed from Normal to Low
blocker resolved. Also setting to "Low" as in comparison to other components where are not covered at all here it is only about executing the modules we already execute in other cases for the RT-case where I see only minor risk that something is breaking for RT, e.g. on the RT kernel, but not on normal SLES.
So I see three different options:
- Keep the existing "just boot, validate the kernel and stop" flow -> least effort, least coverage
- Select the modules especially useful for RT and run these in a custom schedule flow -> highest effort but less risk of modules failing for the same reason as in SLES and we might need to add label multiple times
- Just run the standard console tests + gnome tests based on the default schedule flow as we also have for default SLES -> middle effort, best coverage
Did I miss something? What do you guys prefer?
Updated by riafarov almost 6 years ago
- Due date changed from 2019-03-12 to 2019-03-26
Updated by okurz almost 6 years ago
- Status changed from Workable to New
Please let's discuss my questions #45152#note-11
Updated by okurz almost 6 years ago
Alright. It's the "highest effort" but I consider it still feasible to do within the next sprint in theory. Currently we have quite some tasks already planned for the sprint so we might need to delay this ticket.
Updated by riafarov almost 6 years ago
- Description updated (diff)
- Estimated time set to 3.00 h
Kernel is tested in another test suite.
No modifications of the test modules should be required, only bug report as it should work as good as for SLES product.
Updated by mloviska almost 6 years ago
- Status changed from Workable to Feedback
Updated by JERiveraMoya over 5 years ago
- Status changed from Feedback to In Progress
Updated by mloviska over 5 years ago
- Status changed from In Progress to Feedback
Updated by mloviska over 5 years ago
- Status changed from Feedback to Resolved