Hi Thang,
The concern: When avd_sg_su_si_mod_snd() fails, it internally rolls back all
SUSI state (restores standby/assigned). No message is sent to AvND.
Then the caller proceeds to:
1. avd_sg_su_oper_list_add() — registers SU as pending
2. sg->set_fsm_state(AVD_SG_FSM_SG_REALIGN) — blocks SG
Open question: Since avd_sg_su_si_mod_snd() already restored the SUSI state on
failure (no MODIFY pending on any SUSI), will the SG_REALIGN handler
ever process this SU correctly when a subsequent event arrives? Or is it a dead
entry in the oper list — no SUSI in MODIFY state, so no response will
match, and no completion path will fire?
I have no ideas way forward in failure use case. Just leave open question you
can take a look
Best Regards,
Thien
________________________________
From: Thang Nguyen <[email protected]>
Sent: Wednesday, July 8, 2026 10:02 AM
To: Thien Huynh <[email protected]>; Dat Phan <[email protected]>
Cc: [email protected] <[email protected]>;
Thang Nguyen <[email protected]>
Subject: [PATCH 1/1] amf: fix SI partial assignment after split-brain recovery
in roaming SC [#3402]
When a roaming SC cluster experiences a split-brain and the active
controller reboots then comes back before failover completes, an SI
can get stuck in PARTIALLY_ASSIGNED state with two standby assignments
and no active.
The root cause is in avd_sg_2n_su_chose_asgn(). When avd_sg_2n_act_susi()
returns a_susi=NULL (no active) but s_susi!=NULL (standby exists), the
code enters the a_susi==NULL branch and calls avd_sg_2n_assign_act_si()
for each in-service SU. However, avd_sg_2n_assign_act_si() skips any SI
that already has a SUSI (the existing standby), so no active is assigned.
The function then falls through to the standby section and creates a
duplicate standby assignment.
Fix by detecting the case where only a standby SUSI exists with no
active, and promoting the existing standby SU to active via
avd_sg_su_si_mod_snd() before entering the normal assignment path.
Set the SG FSM to SG_REALIGN so that a new standby will be assigned
to another suitable SU after the promotion completes.
---
src/amf/amfd/sg_2n_fsm.cc | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/src/amf/amfd/sg_2n_fsm.cc b/src/amf/amfd/sg_2n_fsm.cc
index e3d970fa8..df0209647 100644
--- a/src/amf/amfd/sg_2n_fsm.cc
+++ b/src/amf/amfd/sg_2n_fsm.cc
@@ -708,6 +708,24 @@ static AVD_SU *avd_sg_2n_su_chose_asgn(AVD_CL_CB *cb,
AVD_SG *sg) {
avd_sidep_update_si_dep_state_for_all_sis(sg);
a_susi = avd_sg_2n_act_susi(cb, sg, &s_susi);
+ /* Only standby exists, no active. Promote the standby SU to active.
+ * This can happen during split-brain recovery when the active SU's node
+ * rebooted and came back before the failover was fully processed.
+ */
+ if ((a_susi == AVD_SU_SI_REL_NULL) &&
+ (s_susi != AVD_SU_SI_REL_NULL)) {
+ LOG_WA("Only standby '%s' assigned, modifying to active",
+ s_susi->su->name.c_str());
+ if (avd_sg_su_si_mod_snd(cb, s_susi->su, SA_AMF_HA_ACTIVE) ==
+ NCSCC_RC_FAILURE) {
+ LOG_NO("%s:%u: Active role modification failed for %s",
+ __FILE__, __LINE__, s_susi->su->name.c_str());
+ }
+ avd_sg_su_oper_list_add(cb, s_susi->su, false);
+ sg->set_fsm_state(AVD_SG_FSM_SG_REALIGN);
+ goto done;
+ }
+
if (a_susi == AVD_SU_SI_REL_NULL) {
/* No active assignment exists. Scan the ranked list of SUs in the SG
* to identify a in-service SU
--
2.34.1
The information in this email is confidential and may be legally privileged. It
is intended solely for the addressee. Any opinions expressed are mine and do
not necessarily represent the opinions of the Company. Emails are susceptible
to interference. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance on
it, is strictly prohibited and may be unlawful. If you have received this
message in error, do not open any attachments but please notify the Endava
Service Desk on (+44 (0)870 423 0187), and delete this message from your
system. The sender accepts no responsibility for information, errors or
omissions in this email, or for its use or misuse, or for any act committed or
omitted in connection with this communication. If in doubt, please verify the
authenticity of the contents with the sender. Please rely on your own virus
checkers as no responsibility is taken by the sender for any damage rising out
of any bug or virus infection.
Endava plc is a company registered in England under company number 5722669
whose registered office is at 125 Old Broad Street, London, EC2N 1AR, United
Kingdom. Endava plc is the Endava group holding company and does not provide
any services to clients. Each of Endava plc and its subsidiaries is a separate
legal entity and has no liability for another such entity's acts or omissions.
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
