Hi Praveen ack (code review only)
> On 16 Oct 2015, at 11:04 PM, [email protected] wrote: > > 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
