Hi,
It's not problem from sender, the log of mail server showed that all
messages had been delivered successfully. So I resend the patches with
attachment, hope that you receive them this time.
Thanks,
Minh
On 08/11/16 19:43, Nagendra Kumar wrote:
Hi Minh,
I have resent to you the missing patches that I received, as I put myself in
reception list. Anyway, I'm checking this problem.
We didn't get that also.
I think, you have said it before also in #1725 patch context, at that time
also, we had not got.
Please correct the problem now so that we need not take the patches from source
forge.
When needed, it is easier to search in mail box, going to source forge is not
an easy way.
Please re-float the patches again after correcting the problem and let us know.
Thanks
-Nagu
-----Original Message-----
From: minh chau [mailto:minh.c...@dektech.com.au]
Sent: 08 November 2016 13:28
To: Nagendra Kumar; Praveen Malviya; hans.nordeb...@ericsson.com;
gary....@dektech.com.au
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 2 of 2] AMFND: Fix SC failover during headless sync
before standby AMFD comes up [#2162]
Hi Nagu, Praveen
Sorry if any inconvenience. All patches have reached sourceforge and those
can be seen in devel mailing list.
I have resent to you the missing patches that I received, as I put myself in
reception list. Anyway, I'm checking this problem.
Thanks,
Minh
On 08/11/16 18:26, Nagendra Kumar wrote:
Hi Minh,
This is common problem in your patches that only few are
received. Can you please correct it.
Thanks
-Nagu
-----Original Message-----
From: praveen malviya
Sent: 08 November 2016 12:50
To: Minh Hon Chau; hans.nordeb...@ericsson.com; Nagendra Kumar;
gary....@dektech.com.au
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 2 of 2] AMFND: Fix SC failover during headless
sync before standby AMFD comes up [#2162]
Hi Minh,
Patch 0 and 1 are not received. Please resend.
Thanks,
Praveen
On 08-Nov-16 8:53 AM, Minh Hon Chau wrote:
osaf/services/saf/amf/amfnd/di.cc | 7 +++++--
osaf/services/saf/amf/amfnd/susm.cc | 6 ++++++
2 files changed, 11 insertions(+), 2 deletions(-)
This case of SC failover causes new active AMFD getting stuck in
node_up messages
Say first active controller is SC1, which goes down during headless
sync. Therefore, the amfnd on SC2 receives mds_down of AVD, then
both is_avd_down and amfd_sync_required are set to true. When SC2
takes over active role, amfnd on SC2 receives mds_up, but only
is_avd_down is
set to false and the variable amfd_sync_required remains true.
When amfnd-SC2 finishes initiating middleware SU, it needs to send
su_oper message to AMFD, but it is failed to send out due to
amfd_sync_required.
In this scenario of SC failover, amfd_sync_required needs to set to
false when amfnd on SC2 receives su_pres message on middleware SUs.
That means amfnd on active controller does not need to wait for
set_leds message, to be informed that cluster initiation is done, so
that amfnd can sen su_oper messages to AMFD. This logic also aligns
with normal headless scenario, where amfnd on active controller has
amfd_sync_required initially marked as false because no middleware
SUs are initiated. When amfd_sync_required is true that means amfnd
all
middleware SUs are initiated and assigned before headless, thus amfnd
needs to wait for cluster initiation after headless.
diff --git a/osaf/services/saf/amf/amfnd/di.cc
b/osaf/services/saf/amf/amfnd/di.cc
--- a/osaf/services/saf/amf/amfnd/di.cc
+++ b/osaf/services/saf/amf/amfnd/di.cc
@@ -748,7 +748,8 @@ uint32_t avnd_di_oper_send(AVND_CB *cb,
if (avnd_diq_rec_add(cb, &msg) == nullptr) {
rc = NCSCC_RC_FAILURE;
}
- LOG_NO("avnd_di_oper_send() deferred as AMF director is
offline");
+ LOG_NO("avnd_di_oper_send() deferred as AMF director is
offline(%d),"
+ " or sync is required(%d)", cb->is_avd_down,
+cb->amfd_sync_required);
} else {
// We are in normal cluster, send msg to director
msg.info.avd->msg_info.n2d_opr_state.msg_id = ++(cb-
snd_msg_id); @@ -881,7 +882,9 @@ uint32_t
avnd_di_susi_resp_send(AVND_CB
rc = NCSCC_RC_FAILURE;
}
m_AVND_SU_ALL_SI_RESET(su);
- LOG_NO("avnd_di_susi_resp_send() deferred as AMF
director is
offline");
+ LOG_NO("avnd_di_susi_resp_send() deferred as AMF
+ director is
offline(%d),"
+ " or sync is required(%d)",
+ cb->is_avd_down,
+ cb->amfd_sync_required);
+
} else {
// We are in normal cluster, send msg to director
msg.info.avd->msg_info.n2d_su_si_assign.msg_id =
++(cb->snd_msg_id); diff --git a/osaf/services/saf/amf/amfnd/susm.cc
b/osaf/services/saf/amf/amfnd/susm.cc
--- a/osaf/services/saf/amf/amfnd/susm.cc
+++ b/osaf/services/saf/amf/amfnd/susm.cc
@@ -1345,6 +1345,12 @@ uint32_t
avnd_evt_avd_su_pres_evh(AVND_C
goto done;
}
} else { /* => instantiate the su */
+ // Do not need to wait for headless sync if there is no
application SUs
+ // initiated. This is known because here we are receiving
su_pres message
+ // for NCS SUs
+ if (su->is_ncs == true)
+ cb->amfd_sync_required = false;
+
AVND_EVT *evt_ir = 0;
TRACE("Sending to Imm thread.");
evt_ir = avnd_evt_create(cb, AVND_EVT_IR, 0, nullptr,
&info->su_name, 0, 0);
AMFND: Fix SC failover during headless sync before standby AMFD comes up [#2162]
This case of SC failover causes new active AMFD getting stuck in node_up messages
Say first active controller is SC1, which goes down during headless sync. Therefore,
the amfnd on SC2 receives mds_down of AVD, then both is_avd_down and amfd_sync_required
are set to true. When SC2 takes over active role, amfnd on SC2 receives mds_up, but
only is_avd_down is set to false and the variable amfd_sync_required remains true.
When amfnd-SC2 finishes initiating middleware SU, it needs to send su_oper message
to AMFD, but it is failed to send out due to amfd_sync_required.
In this scenario of SC failover, amfd_sync_required needs to set to false when amfnd
on SC2 receives su_pres message on middleware SUs. That means amfnd on active controller
does not need to wait for set_leds message, to be informed that cluster initiation is
done, so that amfnd can sen su_oper messages to AMFD. This logic also aligns with normal
headless scenario, where amfnd on active controller has amfd_sync_required initially
marked as false because no middleware SUs are initiated. When amfd_sync_required is true
that means amfnd all middleware SUs are initiated and assigned before headless, thus
amfnd needs to wait for cluster initiation after headless.
diff --git a/osaf/services/saf/amf/amfnd/di.cc b/osaf/services/saf/amf/amfnd/di.cc
--- a/osaf/services/saf/amf/amfnd/di.cc
+++ b/osaf/services/saf/amf/amfnd/di.cc
@@ -748,7 +752,8 @@ uint32_t avnd_di_oper_send(AVND_CB *cb,
if (avnd_diq_rec_add(cb, &msg) == nullptr) {
rc = NCSCC_RC_FAILURE;
}
- LOG_NO("avnd_di_oper_send() deferred as AMF director is offline");
+ LOG_NO("avnd_di_oper_send() deferred as AMF director is offline(%d),"
+ " or sync is required(%d)", cb->is_avd_down, cb->amfd_sync_required);
} else {
// We are in normal cluster, send msg to director
msg.info.avd->msg_info.n2d_opr_state.msg_id = ++(cb->snd_msg_id);
@@ -881,7 +886,9 @@ uint32_t avnd_di_susi_resp_send(AVND_CB
rc = NCSCC_RC_FAILURE;
}
m_AVND_SU_ALL_SI_RESET(su);
- LOG_NO("avnd_di_susi_resp_send() deferred as AMF director is offline");
+ LOG_NO("avnd_di_susi_resp_send() deferred as AMF director is offline(%d),"
+ " or sync is required(%d)", cb->is_avd_down, cb->amfd_sync_required);
+
} else {
// We are in normal cluster, send msg to director
msg.info.avd->msg_info.n2d_su_si_assign.msg_id = ++(cb->snd_msg_id);
diff --git a/osaf/services/saf/amf/amfnd/susm.cc b/osaf/services/saf/amf/amfnd/susm.cc
--- a/osaf/services/saf/amf/amfnd/susm.cc
+++ b/osaf/services/saf/amf/amfnd/susm.cc
@@ -1345,6 +1345,12 @@ uint32_t avnd_evt_avd_su_pres_evh(AVND_C
goto done;
}
} else { /* => instantiate the su */
+ // Do not need to wait for headless sync if there is no application SUs
+ // initiated. This is known because here we are receiving su_pres message
+ // for NCS SUs
+ if (su->is_ncs == true)
+ cb->amfd_sync_required = false;
+
AVND_EVT *evt_ir = 0;
TRACE("Sending to Imm thread.");
evt_ir = avnd_evt_create(cb, AVND_EVT_IR, 0, nullptr, &info->su_name, 0, 0);
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
