osaf/services/saf/amf/amfd/csi.cc | 3 ---
osaf/services/saf/amf/amfd/imm.cc | 15 +++++++++++++--
osaf/services/saf/amf/amfd/siass.cc | 4 +++-
3 files changed, 16 insertions(+), 6 deletions(-)
In the reported problem, application SI was lock and then unlocked.
When SI got successfully assigned, controller failover was done.
Upon successful fail-over, command : amf-state siass all | grep SI2
does not show any SUSI for this SI.
SUSI for the SI exists in AMFD data base, this can be verified by doing si-swap
operation on the SI or by dumping amfd state. When SI was locked, a job is
added in
IMM job queue for the deletion of SUSI at active when it creates it in AMFD and
at standby
AMFD it is added when it gets the checkpointing request from active. But when
SI was
unlocked, only active added a job for susi creation, but in its checkpointing
standby AMFD
was unable to add. The reason was in function
check_to_create_immjob_at_standby_amfd(),
check was added for internal classIds of classes SaAmfSIAssignment amd
SaAmfCSIAssignment
which is valid for deletion and update. But for creation of SUSI and CSICOMP in
IMM name
of parent i.e SI and CSI is required. Because of this after failover when new
active clears its IMM job list, it only deletes the SUSI but since no create
job was added, user does not see SUSI and CSICOMP for SI and CSI,
respectively.
Patch resolves the problem by adding the check on SI and CSI class id also.
diff --git a/osaf/services/saf/amf/amfd/csi.cc
b/osaf/services/saf/amf/amfd/csi.cc
--- a/osaf/services/saf/amf/amfd/csi.cc
+++ b/osaf/services/saf/amf/amfd/csi.cc
@@ -1104,9 +1104,6 @@ static void avd_create_csiassignment_in_
NULL
};
- if (avd_cb->avail_state_avd != SA_AMF_HA_ACTIVE)
- return;
-
avsv_create_association_class_dn(comp_dn, NULL, "safCSIComp", &dn);
TRACE("Adding %s", dn.value);
diff --git a/osaf/services/saf/amf/amfd/imm.cc
b/osaf/services/saf/amf/amfd/imm.cc
--- a/osaf/services/saf/amf/amfd/imm.cc
+++ b/osaf/services/saf/amf/amfd/imm.cc
@@ -1565,10 +1565,21 @@ bool check_to_create_immjob_at_standby_a
AVSV_AMF_CLASS_ID class_type = AVSV_SA_AMF_CLASS_INVALID;
class_type = object_name_to_class_type(dn);
+ /*
+ SI and CSI are config classes, so AMFD will not create any object for
them
+ in IMM. But for creation of runtime objects of classes SUSI and
CSICOMP, parent
+ name of SI and CSI, respecitvely, will be given. However, for deletion
of SUSI or
+ CSICOMP objects their own dn will be given. Because of this reason
below check
+ includes classType of CSI and SI also.
+ */
if ((class_type == AVSV_SA_AMF_SU) || (class_type == AVSV_SA_AMF_COMP)
||
- (class_type == AVSV_SA_AMF_SI_ASSIGNMENT) ||
- (class_type == AVSV_SA_AMF_CSI_ASSIGNMENT))
+ (class_type == AVSV_SA_AMF_SI_ASSIGNMENT) ||
+ (class_type == AVSV_SA_AMF_CSI_ASSIGNMENT) ||
+ (class_type == AVSV_SA_AMF_SI) ||
+ (class_type == AVSV_SA_AMF_CSI)) {
+ TRACE("Class Type:%s",avd_class_names[class_type]);
return true;
+ }
return false;
}
diff --git a/osaf/services/saf/amf/amfd/siass.cc
b/osaf/services/saf/amf/amfd/siass.cc
--- a/osaf/services/saf/amf/amfd/siass.cc
+++ b/osaf/services/saf/amf/amfd/siass.cc
@@ -241,8 +241,10 @@ AVD_SU_SI_REL *avd_susi_create(AVD_CL_CB
}
done:
+ //ADD susi in imm job queue at both standby and active amfd.
+ if (su_si != NULL)
+ avd_create_susi_in_imm(state, &si->name, &su->name);
if ((ckpt == false) && (su_si != NULL)) {
- avd_create_susi_in_imm(state, &si->name, &su->name);
avd_susi_update_assignment_counters(su_si, AVSV_SUSI_ACT_ASGN,
state, state);
avd_gen_su_ha_state_changed_ntf(cb, su_si);
}
------------------------------------------------------------------------------
_______________________________________________
Opensaf-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
