Project

General

Profile

Actions
Copy link

action #65684

closed

[qe-asg][qem] test order on sles4sap makes no sense

Added by dzedro about 4 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
jadamek
Category:
Bugs in existing tests
Target version:
-
Start date:
2020-04-16
Due date:
% Done:

100%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario sle-12-SP2-SAP-DVD-Updates-x86_64-qam-sles4sap_hana_node02@64bit fails in
check_after_reboot

Test suite description

Maintainer: qa-css team, QA and QAM for HA/SAP. Test SAP HANA installation and configure a cluster with system replication.

Reproducible

Fails since (at least) Build 20200416-1 (current job)

Expected result

Last good: 20200415-1 (or more recent)

Further details

Always latest result in this scenario: latest

Actions
Copy link
 #1

Updated by dzedro about 4 years ago

on one node is scheduled, fencing->boot_to_desktop->check_after_reboot
on another node is scheduled fencing->check_after_reboot
Also in fencing test both nodes execute fencing on node01 ?

Actions
Copy link
 #2

Updated by jadamek about 4 years ago

dzedro wrote:

on one node is scheduled, fencing->boot_to_desktop->check_after_reboot
on another node is scheduled fencing->check_after_reboot
Also in fencing test both nodes execute fencing on node01 ?

Fencing module is loaded in all nodes but fencing action is conditioning by:

assert_script_run 'crm -F node fence ' . get_node_to_join if is_node(2);

So only node2 is executing a fencing command here.

We are using the same in our build validation group for 15SP2.
Let me time to check please.

Actions
Copy link
 #3

Updated by jadamek about 4 years ago

As far as I can see, this is just a sporadic issue because previous and next builds succeeded.
I will spend more time next week to find why node2 rebooted.

Actions
Copy link
 #5

Updated by tjyrinki_suse almost 4 years ago

  • Status changed from New to Workable
Actions
Copy link
 #6

Updated by openqa_review over 3 years ago

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: qam_ha_2nodes_02
https://openqa.suse.de/tests/4546038

To prevent further reminder comments one of the following options should be followed:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released"
  3. The label in the openQA scenario is removed
Actions
Copy link
 #7

Updated by tjyrinki_suse over 3 years ago

  • Subject changed from [qam] test order on sles4sap makes no sense to [qe-core][qam] test order on sles4sap makes no sense
Actions
Copy link
 #8

Updated by tjyrinki_suse over 3 years ago

  • Subject changed from [qe-core][qam] test order on sles4sap makes no sense to [qe-asg][qam] test order on sles4sap makes no sense
Actions
Copy link
 #9

Updated by tjyrinki_suse over 3 years ago

  • Subject changed from [qe-asg][qam] test order on sles4sap makes no sense to [qe-asg][qem] test order on sles4sap makes no sense
Actions
Copy link
 #10

Updated by tjyrinki_suse over 3 years ago

  • Assignee set to jadamek

I'm using jadamek to assign like qam-openqa reviewer did, but meaning the whole QE ASG team as the assignee.

Actions
Copy link
 #11

Updated by jadamek over 3 years ago

I think we can close this ticket, we do not see this issue anymore.
Another issue related to check_after_boot is tackled in this ticket https://progress.opensuse.org/issues/80282

Actions
Copy link
 #12

Updated by jadamek over 3 years ago

  • Status changed from Workable to Resolved
  • % Done changed from 0 to 100
Actions
Copy link

Also available in: Atom PDF