Standby controller reboots if active controller gracefully reboots

Bug #1906556 reported by Eric MacDonald
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
StarlingX
Fix Released
Medium
Eric MacDonald

Bug Description

SM fails the the standby controller on its way down from a spontaneous graceful reboot.

Although gracefully rebooting the active controller is not something that is supported, the fact that the standby controller is also taken down by that event is very undesirable.

Issue does not happen on a forced reboot (with --force option) of the active controller.

This is because of the timing around the graceful process shutdown leads to SM experiencing a heartbeat failure with its peer without the maintenance heartbeat cluster information providing the necessary data to allow SM to know that it needs to be the survivor in this case.

Suggest implementing a change in maintenance to make its heartbeat cluster state change notifications more timely.

Severity
--------
Minor: System recovers after unsupported spontaneous graceful reboot of the active controller.

Steps to Reproduce
------------------
In a duplex system 'sudo reboot' the active controller

Expected Behavior
------------------
SM on the standby controller takes over activity

Actual Behavior
----------------
SM on the standby controller fails itself and gets rebooted by maintenance

Reproducibility
---------------
Highly reproducible

System Configuration
--------------------
Duplex system

Branch/Pull Time/Commit
-----------------------
starlingx/master at time this issue was created.
Actually, long standing behavior.

Last Pass
---------
Unknown

Timestamp/Logs
--------------
from /var/log/mtcAgent.log

2020-08-31T14:39:06.476 [3576821.01162] controller-0 mtcAgent hbs nodeClass.cpp (4061) set_mtce_flags :Error : controller-1 reported unhealthy by SM (Mgmnt)

from /var/log/sm.log

2020-08-31T14:39:03.000 controller-1 sm: debug time[766.694] log<441> INFO: sm[88025]: sm_failover_ss.c(352): Loss of heartbeat ALL
2020-08-31T14:39:03.000 controller-1 sm: debug time[766.694] log<442> INFO: sm[88025]: sm_failover_ss.c(478): host reaches 11 nodes, peer reaches 11 nodes, peer will be survivor

Test Activity
-------------
[Feature Testing, Regression Testing]

Workaround
----------
Don't gracefully reboot the active controller

Changed in starlingx:
assignee: nobody → Eric MacDonald (rocksolidmtce)
Ghada Khalil (gkhalil)
tags: added: stx.metal
Ghada Khalil (gkhalil)
Changed in starlingx:
importance: Undecided → Critical
importance: Critical → Low
status: New → Triaged
tags: added: stx.5.0
Changed in starlingx:
importance: Low → Medium
Revision history for this message
Eric MacDonald (rocksolidmtce) wrote :
Changed in starlingx:
status: Triaged → Fix Released
Ghada Khalil (gkhalil)
summary: - Standby controller reboots if active controller spontaneously gracefully
- reboots
+ Standby controller reboots if active controller gracefully reboots
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to metal (f/centos8)

Fix proposed to branch: f/centos8
Review: https://review.opendev.org/c/starlingx/metal/+/792250

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to metal (f/centos8)
Download full text (34.9 KiB)

Reviewed: https://review.opendev.org/c/starlingx/metal/+/792250
Committed: https://opendev.org/starlingx/metal/commit/6c2905e665ceeebfa7717c9cbccc1c277d10966b
Submitter: "Zuul (22348)"
Branch: f/centos8

commit 5942a56ec6f0b265ca6d1c8c800fe84c4a22860f
Author: Eric MacDonald <email address hidden>
Date: Thu May 13 15:57:43 2021 +0000

    Revert "Align partitions created by kickstarters"

    This reverts commit 0e89acc83c616741952a068a3ff07ba91440eff8.

    Reason for revert: Review should have been abandoned rather than merged.

    Change-Id: I95f1e151183f122d93b834ab2a785736e5a8ef12
    Closes-Bug: 1928341

commit c7c341b198e79bb98f443c7c07f671c6387075af
Author: Don Penney <email address hidden>
Date: Fri May 7 08:56:06 2021 -0400

    Add /pxeboot/grubx64.efi symlink for UEFI pxeboot

    UEFI pxeboot with shim.efi looks for the grubx64.efi in the tftpboot
    root directory. This update creates a symlink to the
    /pxeboot/EFI/grubx64.efi file in /pxeboot.

    Change-Id: Iabf8ec89d0af6e6b1a62e20159ecdfa16729444e
    Partial-Bug: 1927730
    Signed-off-by: Don Penney <email address hidden>

commit ce7529964932a9fd1cc10ce18dbe11e89ee02223
Author: Eric MacDonald <email address hidden>
Date: Wed May 5 19:05:55 2021 -0400

    Fix enabling heartbeat of self from the peer controller

    This issue only occurs over an hbsAgent process restart
    where the ready event response does not include the
    heartbeat start of the peer controller.

    This update reverts a small code change that was
    introduced by the following update.

    https://review.opendev.org/c/starlingx/metal/+/788495

    Remove the my_hostname gate introduced at line 1267 of
    mtcCtrlMsg.cpp because it prevents enabling heartbeat
    of self by the peer controller.

    Change-Id: Id72c35f25e2a5231a8a8363a35a81e042f00085e
    Closes-Bug: 1922584
    Signed-off-by: Eric MacDonald <email address hidden>

commit 48978d804d6f22130d0bd8bd17f361441024bc6c
Author: Eric MacDonald <email address hidden>
Date: Wed Apr 28 09:39:19 2021 -0400

    Improved maintenance handling of spontaneous active controller reboot

    Performing a forced reboot of the active controller sometimes
    results in a second reboot of that controller. The cause of the
    second reboot was due to its reported uptime in the first mtcAlive
    message, following the reboot, as greater than 10 minutes.

    Maintenance has a long standing graceful recovery threshold of
    10 minutes. Meaning that if a host looses heartbeat and enters
    Graceful Recovery, if the uptime value extracted from the first
    mtcAlive message following the recovery of that host exceeds 10
    minutes, then maintenance interprets that the host did not reboot.
    If a host goes absent for longer than this threshold then for
    reasons not limited to security, maintenance declares the host
    as 'failed' and force re-enables it through a reboot.

    With the introduction of containers and addition of new features
    over the last few releases, boot times on some servers are
    approaching the 10 minute threshold an...

tags: added: in-f-centos8
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.