action #45149

[sle][functional][y][rt][bsc#1119412] validate booted kernel (or workaround for kernel selection)

Added by mloviska about 1 year ago. Updated about 1 year ago.

Status:ResolvedStart date:13/12/2018
Priority:NormalDue date:12/02/2019
Assignee:mloviska% Done:

0%

Category:New testEstimated time:5.00 hours
Target version:SUSE QA tests - Milestone 22
Difficulty:
Duration: 44

Description

Observation

openQA test in scenario sle-15-SP1-Installer-DVD-x86_64-rt-product@64bit has false positive results, because test does not evaluate what kind of kernel has been booted
grub_test
I would personally prefer to fail test suite as long as SUT does not boot rt kernel by default.

Expected result

Linux zoidberg 4.12.14-7-rt #1 SMP PREEMPT RT Wed Oct 24 07:40:06 UTC 2018 (f4a4855) x86_64 x86_64 x86_64 GNU/Linux

Acceptance criteria

  1. Instructions from Release Notes are validated
  2. There is a test module which enables RT kernel and validates it

Suggestions


Related issues

Related to openQA Tests - action #45152: [sle][functional][y][rt] extend test coverage of RT insta... Resolved 13/12/2018 26/03/2019

History

#1 Updated by mloviska about 1 year ago

  • Parent task set to #43199

#2 Updated by okurz about 1 year ago

  • Subject changed from [sle][functional][y][RT][bsc#1119412] validate booted kernel to [sle][functional][y][rt][bsc#1119412] validate booted kernel
  • Category changed from Bugs in existing tests to New test
  • Target version set to Milestone 22

Good that you have this reported. I will change category to "New test" though as this is what we commonly use according to https://progress.opensuse.org/projects/openqatests/wiki#ticket-workflow do describe any "extension of test coverage". "Bugs in existing tests" means basically: "It fails now but worked in before" which might be misleading to some because the test actually is "green" :)

#3 Updated by okurz about 1 year ago

  • Status changed from New to Blocked
  • Assignee set to okurz

waiting for clarification (question in bug)

#4 Updated by Jeffreycheung about 1 year ago

okurz wrote:

Good that you have this reported. I will change category to "New test" though as this is what we commonly use according to https://progress.opensuse.org/projects/openqatests/wiki#ticket-workflow do describe any "extension of test coverage". "Bugs in existing tests" means basically: "It fails now but worked in before" which might be misleading to some because the test actually is "green" :)

It worked in the past because RT planned to be released 3 months later after SLES FCS. At that time, RT kernel version higher than the SLES GA version and thus it can always boot to RT kernel.

For SLE15, RT aligned the release cycle with SLES, thus RT kernel version always behind SLES. It is due to RT accept the commit that has been stable in SLES and not update the kernel as frequent as SLES.

The current workaround is to mention this in RT Release Notes

#5 Updated by mloviska about 1 year ago

Jeffreycheung wrote:

The current workaround is to mention this in RT Release Notes

As long as we are talking about workarounds, do we plan to ship adequate grub configs for RT in the future ? So the system boots RT kernel without any user intervention.

#6 Updated by Jeffreycheung about 1 year ago

mloviska wrote:

Jeffreycheung wrote:

The current workaround is to mention this in RT Release Notes


As long as we are talking about workarounds, do we plan to ship adequate grub configs for RT in the future ? So the system boots RT kernel without any user intervention.

Well, I left comment in bug that this would be WONFIX in RT15 SP1, I will try to fix it in RT15 SP2.

#7 Updated by mloviska about 1 year ago

Jeffreycheung wrote:

mloviska wrote:

Jeffreycheung wrote:

The current workaround is to mention this in RT Release Notes


As long as we are talking about workarounds, do we plan to ship adequate grub configs for RT in the future ? So the system boots RT kernel without any user intervention.


Well, I left comment in bug that this would be WONFIX in RT15 SP1, I will try to fix it in RT15 SP2.

Alright then, so basically this means that we need to come with a workaround in our test suites as long as we want keep rt test modules as they are designed (kmp_modules, rt_is_realtime, rt_peak_pci, rt_preempt_test). I guess that rt_devel_packages can stay as it is in any case.
https://openqa.suse.de/tests/2226731#

#8 Updated by okurz about 1 year ago

  • Subject changed from [sle][functional][y][rt][bsc#1119412] validate booted kernel to [sle][functional][y][rt][bsc#1119412] validate booted kernel (or workaround for kernel selection)
  • Description updated (diff)
  • Due date set to 12/02/2019
  • Status changed from Blocked to Workable
  • Assignee deleted (okurz)

Exactly. Rephrased the ticket accordingly to acommodate the workaround.

#9 Updated by riafarov about 1 year ago

  • Description updated (diff)
  • Estimated time set to 5.00

#10 Updated by mloviska about 1 year ago

  • Status changed from Workable to In Progress
  • Assignee set to mloviska

#11 Updated by mloviska about 1 year ago

  • Related to action #45152: [sle][functional][y][rt] extend test coverage of RT installation added

#12 Updated by mloviska about 1 year ago

It was not so hard to resurrect boot_rt_kernel
http://eris.suse.cz/tests/11336#step/boot_rt_kernel/7

#13 Updated by mloviska about 1 year ago

  • Status changed from In Progress to Feedback

#14 Updated by okurz about 1 year ago

awesome you could reuse that :)

#15 Updated by riafarov about 1 year ago

PR merged.

#16 Updated by mloviska about 1 year ago

  • Status changed from Feedback to In Progress

I will update openQA test suites

#18 Updated by mloviska about 1 year ago

  • Status changed from Feedback to Resolved

#19 Updated by riafarov about 1 year ago

https://openqa.suse.de/tests/2435812 failed, one test suite failed due to mismatching needle. As for rt_preempt_test we could exclude it as we plan to replace it anyway. WDYT?

#20 Updated by mloviska about 1 year ago

Needle issue has been already fixed.
https://openqa.suse.de/tests/2436306#step/kmp_modules/37

Sure we can exclude rt_preempt_test, I just intended to make it visible that it has a problem. Beside that, I have already labeled the job run with a bug report and poo, to make it easier for reviewers.

Also available in: Atom PDF