[tickets] [opensaf:tickets] #1287 IMM: Document AdminOwner clear/release minor discrepancy with SAF spec
- **status**: review -- fixed --- ** [tickets:#1287] IMM: Document AdminOwner clear/release minor discrepancy with SAF spec** **Status:** fixed **Milestone:** 4.5.2 **Created:** Fri Mar 27, 2015 11:16 AM UTC by Anders Bjornerstedt **Last Updated:** Tue Apr 14, 2015 07:42 AM UTC **Owner:** Anders Bjornerstedt See ticket #1278: https://sourceforge.net/p/opensaf/tickets/1278 According to the SAF spec ERR_BUSY should be given as response to an AdminOwnerRelease/Clear operation if there is currently an admin-operation on-going directed at some object that the release/clear is targeting. The Admin-owner mechanism is an access-control mechanism. After access has been granted (in this case for an admin-operation) there is no real point in insisting that the admin-ownership must be valid until the admin-op completes. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1287 IMM: Document AdminOwner clear/release minor discrepancy with SAF spec
- **Milestone**: 4.4.2 -- 4.5.2 - **Comment**: changeset: 6474:4307262dd0d8 tag: tip parent: 6461:65d726809fde user:Anders Bjornerstedt anders.bjornerst...@ericsson.com date:Fri Apr 10 14:26:27 2015 +0200 summary: IMM: Document AdminOwner clear/release minor discrepancy with SAF spec [#1287] changeset: 6473:46e07c8e11c9 branch: opensaf-4.6.x parent: 6469:79a0041f73cc user:Anders Bjornerstedt anders.bjornerst...@ericsson.com date:Fri Apr 10 14:26:27 2015 +0200 summary: IMM: Document AdminOwner clear/release minor discrepancy with SAF spec [#1287] changeset: 6472:3afd398b3d36 branch: opensaf-4.5.x parent: 6468:ccf51409672a user:Anders Bjornerstedt anders.bjornerst...@ericsson.com date:Fri Apr 10 14:26:27 2015 +0200 summary: IMM: Document AdminOwner clear/release minor discrepancy with SAF spec [#1287] --- ** [tickets:#1287] IMM: Document AdminOwner clear/release minor discrepancy with SAF spec** **Status:** review **Milestone:** 4.5.2 **Created:** Fri Mar 27, 2015 11:16 AM UTC by Anders Bjornerstedt **Last Updated:** Fri Apr 10, 2015 12:40 PM UTC **Owner:** Anders Bjornerstedt See ticket #1278: https://sourceforge.net/p/opensaf/tickets/1278 According to the SAF spec ERR_BUSY should be given as response to an AdminOwnerRelease/Clear operation if there is currently an admin-operation on-going directed at some object that the release/clear is targeting. The Admin-owner mechanism is an access-control mechanism. After access has been granted (in this case for an admin-operation) there is no real point in insisting that the admin-ownership must be valid until the admin-op completes. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] Re: #1312 AMF: NodeFailover during SiSwap leaves SG UnStable
Please see inline with [Praveen].
Thanks
Praveen
On 14-Apr-15 4:50 PM, Minh Hon Chau wrote:
The candidate patch below is tested, working fine
diff --git a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
--- a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
+++ b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
@@ -2973,8 +2973,8 @@ void SG_2N::node_fail_su_oper(AVD_SU /su
if available, or same SU will get standby assignment after repair.
//
su-set_su_switch(AVSV_SI_TOGGLE_STABLE);
- m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_STABLE);
- complete_siswap(a_susi-su, SA_AIS_OK);
+ avd_sg_su_oper_list_add(cb, a_susi-su, false);
+ m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_SG_REALIGN);
} else {
avd_sg_su_oper_list_add(cb, a_susi-su, false);
m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_SG_REALIGN);
But this will contradict with patch of #309 as below.
Message: 2
Date: Mon, 28 Jul 2014 04:24:13 +0530
From: praveen.malv...@oracle.com
Subject: [devel] [PATCH 1 of 1] amfd : fix node failover while
assigning standby state during si-swap {#309]
To: hans.fe...@ericsson.com, nagendr...@oracle.com,
hans.nordeb...@ericsson.com
Cc: opensaf-de...@lists.sourceforge.net
Message-ID: 99360b761ba19f495934.1406501653@CON-PC
mailto:99360b761ba19f495934.1406501653@CON-PC
Content-Type: text/plain; charset=us-ascii
osaf/services/saf/amf/amfd/sg_2n_fsm.cc | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
Two si-swap operations are performed. Si-swap fails second time if fault
occurs during standby assignment and it leads to node-failover escalation
during first si-wap
Second si-swap fails because SG remain unstable. This particular case
is not handle in SG FSM of 2N model.
Patch fixes the problem by making SG stable.
diff --git a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
--- a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
+++ b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
@@ -59,7 +59,7 @@ static void complete_siswap(AVD_SU /su,
// si-invocation field is not check pointed. If controller failovers
when si-swap
operation is in progress, si-invocation will be zero on the new active
controller.
Log an error when si-swap operation completes.//
- LOG_ER(Operation done, but invocationId for the operation on SI not
found '%s', su-name.value);
+ TRACE(Operation done, but invocationId for the operation on SI not
found '%s', su-name.value);
}
TRACE_LEAVE();
}
@@ -2929,16 +2929,28 @@ static void avd_sg_2n_node_fail_su_oper(
// the admin state of the SU is shutdown change it to lock. //
if (su-saAmfSUAdminState == SA_AMF_ADMIN_SHUTTING_DOWN) {
su-set_admin_state(SA_AMF_ADMIN_LOCKED);
+ avd_sg_su_oper_list_add(cb, a_susi-su, false);
+ m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_SG_REALIGN);
} else if (su_node_ptr-saAmfNodeAdminState == SA_AMF_ADMIN_SHUTTING_DOWN) {
m_AVD_IS_NODE_LOCK((su_node_ptr), flag);
if (flag == true) {
node_admin_state_set(su_node_ptr, SA_AMF_ADMIN_LOCKED);
}
- } else {
- su-set_su_switch(AVSV_SI_TOGGLE_STABLE);
+ avd_sg_su_oper_list_add(cb, a_susi-su, false);
+ m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_SG_REALIGN);
+ } else {
+
+ // During si-swap while standby assignment is going on, if Nodefailover
+ or SU failover got escalated then toggle SU switch state and make SG
+ stable. After SG becomes stable, spare SU will be instantiated,
+ if available, or same SU will get standby assignment after repair.
+ //
+ if (su-su_switch == AVSV_SI_TOGGLE_SWITCH) {
+ su-set_su_switch(AVSV_SI_TOGGLE_STABLE);
+ m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_STABLE);
+ complete_siswap(a_susi-su, SA_AIS_OK);
+ }
}
There is one more fix in this area #992.
In both #309 and #1312 occurs during si-swap . So above if condition
will hit in both #309 (for standby assignment) and #1312 (for quiesced
assignment and active inprogress). In both of these tickets it is
standby SU or the su that will become standby faults.
SO inside
if (su-su_switch == AVSV_SI_TOGGLE_SWITCH) {
}
I think, if and else can be maintained like
if (Active is marked assigned ) {
then #309 (which marks the SG stable)
} else if (active assignment is still going on) {
fix of #1312 (SG will not become stable).
}
Thanks
Praveen
- avd_sg_su_oper_list_add(cb, a_susi-su, false);
- m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_SG_REALIGN);
} // if (a_susi-su != su) */
else {
if (s_susi != AVD_SU_SI_REL_NULL) {
*[tickets:#1312] http://sourceforge.net/p/opensaf/tickets/1312 AMF:
NodeFailover during SiSwap leaves SG UnStable*
*Status:* assigned
*Milestone:* 4.4.2
*Created:* Fri Apr 10, 2015 10:57 AM UTC by Minh Hon Chau
*Last Updated:* Fri Apr 10, 2015 11:04 AM UTC
*Owner:* Minh Hon Chau
* Configuration:
2 2N SU1, SU2 hosted in SCs
1 sponsored SI (AGENT) and some dependent SIs (MTZ, ACA,
Re: [tickets] [opensaf:tickets] #1312 AMF: NodeFailover during SiSwap leaves SG UnStable
Please see inline with [Praveen].
Thanks
Praveen
On 14-Apr-15 4:50 PM, Minh Hon Chau wrote:
The candidate patch below is tested, working fine
diff --git a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
--- a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
+++ b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
@@ -2973,8 +2973,8 @@ void SG_2N::node_fail_su_oper(AVD_SU /su
if available, or same SU will get standby assignment after repair.
//
su-set_su_switch(AVSV_SI_TOGGLE_STABLE);
- m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_STABLE);
- complete_siswap(a_susi-su, SA_AIS_OK);
+ avd_sg_su_oper_list_add(cb, a_susi-su, false);
+ m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_SG_REALIGN);
} else {
avd_sg_su_oper_list_add(cb, a_susi-su, false);
m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_SG_REALIGN);
But this will contradict with patch of #309 as below.
Message: 2
Date: Mon, 28 Jul 2014 04:24:13 +0530
From: praveen.malv...@oracle.com
Subject: [devel] [PATCH 1 of 1] amfd : fix node failover while
assigning standby state during si-swap {#309]
To: hans.fe...@ericsson.com, nagendr...@oracle.com,
hans.nordeb...@ericsson.com
Cc: opensaf-de...@lists.sourceforge.net
Message-ID: 99360b761ba19f495934.1406501653@CON-PC
mailto:99360b761ba19f495934.1406501653@CON-PC
Content-Type: text/plain; charset=us-ascii
osaf/services/saf/amf/amfd/sg_2n_fsm.cc | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
Two si-swap operations are performed. Si-swap fails second time if fault
occurs during standby assignment and it leads to node-failover escalation
during first si-wap
Second si-swap fails because SG remain unstable. This particular case
is not handle in SG FSM of 2N model.
Patch fixes the problem by making SG stable.
diff --git a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
--- a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
+++ b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
@@ -59,7 +59,7 @@ static void complete_siswap(AVD_SU /su,
// si-invocation field is not check pointed. If controller failovers
when si-swap
operation is in progress, si-invocation will be zero on the new active
controller.
Log an error when si-swap operation completes.//
- LOG_ER(Operation done, but invocationId for the operation on SI not
found '%s', su-name.value);
+ TRACE(Operation done, but invocationId for the operation on SI not
found '%s', su-name.value);
}
TRACE_LEAVE();
}
@@ -2929,16 +2929,28 @@ static void avd_sg_2n_node_fail_su_oper(
// the admin state of the SU is shutdown change it to lock. //
if (su-saAmfSUAdminState == SA_AMF_ADMIN_SHUTTING_DOWN) {
su-set_admin_state(SA_AMF_ADMIN_LOCKED);
+ avd_sg_su_oper_list_add(cb, a_susi-su, false);
+ m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_SG_REALIGN);
} else if (su_node_ptr-saAmfNodeAdminState == SA_AMF_ADMIN_SHUTTING_DOWN) {
m_AVD_IS_NODE_LOCK((su_node_ptr), flag);
if (flag == true) {
node_admin_state_set(su_node_ptr, SA_AMF_ADMIN_LOCKED);
}
- } else {
- su-set_su_switch(AVSV_SI_TOGGLE_STABLE);
+ avd_sg_su_oper_list_add(cb, a_susi-su, false);
+ m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_SG_REALIGN);
+ } else {
+
+ // During si-swap while standby assignment is going on, if Nodefailover
+ or SU failover got escalated then toggle SU switch state and make SG
+ stable. After SG becomes stable, spare SU will be instantiated,
+ if available, or same SU will get standby assignment after repair.
+ //
+ if (su-su_switch == AVSV_SI_TOGGLE_SWITCH) {
+ su-set_su_switch(AVSV_SI_TOGGLE_STABLE);
+ m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_STABLE);
+ complete_siswap(a_susi-su, SA_AIS_OK);
+ }
}
There is one more fix in this area #992.
In both #309 and #1312 occurs during si-swap . So above if condition
will hit in both #309 (for standby assignment) and #1312 (for quiesced
assignment and active inprogress). In both of these tickets it is
standby SU or the su that will become standby faults.
SO inside
if (su-su_switch == AVSV_SI_TOGGLE_SWITCH) {
}
I think, if and else can be maintained like
if (Active is marked assigned ) {
then #309 (which marks the SG stable)
} else if (active assignment is still going on) {
fix of #1312 (SG will not become stable).
}
Thanks
Praveen
- avd_sg_su_oper_list_add(cb, a_susi-su, false);
- m_AVD_SET_SG_FSM(cb, (su-sg_of_su), AVD_SG_FSM_SG_REALIGN);
} // if (a_susi-su != su) */
else {
if (s_susi != AVD_SU_SI_REL_NULL) {
*[tickets:#1312] http://sourceforge.net/p/opensaf/tickets/1312 AMF:
NodeFailover during SiSwap leaves SG UnStable*
*Status:* assigned
*Milestone:* 4.4.2
*Created:* Fri Apr 10, 2015 10:57 AM UTC by Minh Hon Chau
*Last Updated:* Fri Apr 10, 2015 11:04 AM UTC
*Owner:* Minh Hon Chau
* Configuration:
2 2N SU1, SU2 hosted in SCs
1 sponsored SI (AGENT) and some dependent SIs (MTZ, ACA,
[tickets] [opensaf:tickets] #1303 IMM: APIs assert when the length of the object using SaNameT is more than 256
- **status**: review -- fixed - **Comment**: opensaf-4.5.x: changeset: 6475:9efc31715bdf branch: opensaf-4.5.x parent: 6472:3afd398b3d36 user:Zoran Milinkovic zoran.milinko...@ericsson.com date:Fri Apr 10 14:12:58 2015 +0200 summary: imm: validate SaNameT value before osaf_extended_name_length [#1303] - opensaf-4.6.x: changeset: 6476:712340762044 branch: opensaf-4.6.x parent: 6473:46e07c8e11c9 user:Zoran Milinkovic zoran.milinko...@ericsson.com date:Fri Apr 10 14:15:49 2015 +0200 summary: imm: validate SaNameT value before osaf_extended_name_length [#1303] - default(4.7): changeset: 6477:29cbb9e3c859 tag: tip parent: 6474:4307262dd0d8 user:Zoran Milinkovic zoran.milinko...@ericsson.com date:Fri Apr 10 14:15:49 2015 +0200 summary: imm: validate SaNameT value before osaf_extended_name_length [#1303] --- ** [tickets:#1303] IMM: APIs assert when the length of the object using SaNameT is more than 256 ** **Status:** fixed **Milestone:** 4.5.2 **Created:** Mon Apr 06, 2015 08:48 AM UTC by Sirisha Alla **Last Updated:** Fri Apr 10, 2015 12:36 PM UTC **Owner:** Zoran Milinkovic This issue is seen on changeset 6377 (46FC Tag). When IMM agents using old APIs (having SaNameT) specifies the length of object greater than 256, application asserts. bt of the core: Program terminated with signal 6, Aborted. #0 0x7fe800983b55 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x7fe800983b55 in raise () from /lib64/libc.so.6 #1 0x7fe800985131 in abort () from /lib64/libc.so.6 #2 0x7fe7ffe2437a in __osafassert_fail () from /usr/lib64/libopensaf_core.so.0 #3 0x7fe7ffe204b3 in osaf_extended_name_length () from /usr/lib64/libopensaf_core.so.0 #4 0x7fe8000a2dac in saImmOmAdminOperationInvoke_o2 () at imma_om_api.c:3569 Till 4.5 INVALID_PARAM is returned to the application. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1314 smfd: when rebootAffectedNodes is enabled, nodes are in some cases not properly rebooted
--- ** [tickets:#1314] smfd: when rebootAffectedNodes is enabled, nodes are in some cases not properly rebooted** **Status:** assigned **Milestone:** 4.4.2 **Created:** Tue Apr 14, 2015 11:11 AM UTC by Ingvar Bergström **Last Updated:** Tue Apr 14, 2015 11:11 AM UTC **Owner:** Ingvar Bergström In single step upgrades forAdd/Remove: When rebootAffectedNodes is enabled and sw bundles list it's own plmExecEnv nodes for specific sw bundles, the specified nodes are not rebooted. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1312 AMF: NodeFailover during SiSwap leaves SG UnStable
The candidate patch below is tested, working fine
-
diff --git a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
--- a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
+++ b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
@@ -2973,8 +2973,8 @@ void SG_2N::node_fail_su_oper(AVD_SU *su
if available, or same SU will get
standby assignment after repair.
*/
su-set_su_switch(AVSV_SI_TOGGLE_STABLE);
- m_AVD_SET_SG_FSM(cb, (su-sg_of_su),
AVD_SG_FSM_STABLE);
- complete_siswap(a_susi-su, SA_AIS_OK);
+ avd_sg_su_oper_list_add(cb, a_susi-su,
false);
+ m_AVD_SET_SG_FSM(cb, (su-sg_of_su),
AVD_SG_FSM_SG_REALIGN);
} else {
avd_sg_su_oper_list_add(cb, a_susi-su,
false);
m_AVD_SET_SG_FSM(cb, (su-sg_of_su),
AVD_SG_FSM_SG_REALIGN);
But this will contradict with patch of #309 as below.
--
Message: 2
Date: Mon, 28 Jul 2014 04:24:13 +0530
From: praveen.malv...@oracle.com
Subject: [devel] [PATCH 1 of 1] amfd : fix node failover while
assigning standby state during si-swap {#309]
To: hans.fe...@ericsson.com, nagendr...@oracle.com,
hans.nordeb...@ericsson.com
Cc: opensaf-de...@lists.sourceforge.net
Message-ID: 99360b761ba19f495934.1406501653@CON-PC
Content-Type: text/plain; charset=us-ascii
osaf/services/saf/amf/amfd/sg_2n_fsm.cc | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
Two si-swap operations are performed. Si-swap fails second time if fault
occurs during standby assignment and it leads to node-failover escalation
during first si-wap
Second si-swap fails because SG remain unstable. This particular case
is not handle in SG FSM of 2N model.
Patch fixes the problem by making SG stable.
diff --git a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
--- a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
+++ b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
@@ -59,7 +59,7 @@ static void complete_siswap(AVD_SU *su,
/* si-invocation field is not check pointed. If controller
failovers when si-swap
operation is in progress, si-invocation will be zero on the
new active controller.
Log an error when si-swap operation completes.*/
- LOG_ER(Operation done, but invocationId for the operation on
SI not found '%s', su-name.value);
+ TRACE(Operation done, but invocationId for the operation on SI
not found '%s', su-name.value);
}
TRACE_LEAVE();
}
@@ -2929,16 +2929,28 @@ static void avd_sg_2n_node_fail_su_oper(
/* the admin state of the SU is shutdown change it to
lock. */
if (su-saAmfSUAdminState ==
SA_AMF_ADMIN_SHUTTING_DOWN) {
su-set_admin_state(SA_AMF_ADMIN_LOCKED);
+ avd_sg_su_oper_list_add(cb, a_susi-su, false);
+ m_AVD_SET_SG_FSM(cb, (su-sg_of_su),
AVD_SG_FSM_SG_REALIGN);
} else if (su_node_ptr-saAmfNodeAdminState ==
SA_AMF_ADMIN_SHUTTING_DOWN) {
m_AVD_IS_NODE_LOCK((su_node_ptr), flag);
if (flag == true) {
node_admin_state_set(su_node_ptr,
SA_AMF_ADMIN_LOCKED);
}
- } else {
- su-set_su_switch(AVSV_SI_TOGGLE_STABLE);
+ avd_sg_su_oper_list_add(cb, a_susi-su, false);
+ m_AVD_SET_SG_FSM(cb, (su-sg_of_su),
AVD_SG_FSM_SG_REALIGN);
+ } else {
+
+ /* During si-swap while standby assignment is
going on, if Nodefailover
+ or SU failover got escalated then toggle SU
switch state and make SG
+ stable. After SG becomes stable, spare SU
will be instantiated,
+ if available, or same SU will get standby
assignment after repair.
+*/
+ if (su-su_switch == AVSV_SI_TOGGLE_SWITCH) {
+
su-set_su_switch(AVSV_SI_TOGGLE_STABLE);
+ m_AVD_SET_SG_FSM(cb, (su-sg_of_su),
AVD_SG_FSM_STABLE);
+ complete_siswap(a_susi-su, SA_AIS_OK);
+ }
[tickets] [opensaf:tickets] #785 Sending USR2 signal to logd is not resulting in the expected behaviour
- **status**: unassigned -- invalid - **Comment**: This is no longer an issue. Command does work in current OpenSAF UML cluster --- ** [tickets:#785] Sending USR2 signal to logd is not resulting in the expected behaviour ** **Status:** invalid **Milestone:** future **Created:** Fri Feb 14, 2014 06:10 AM UTC by manu **Last Updated:** Fri Feb 14, 2014 06:10 AM UTC **Owner:** nobody Execution of the following command on the controller node does not lead to any trace file as mentioned in the logsv README pkill -USR2 osaflogd However kill -12 `pgrep osaflogd` worked. The README needs to be updated accordingly. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1107 IMM: Provide an admin-operation for aborting all non-critical CCBs
- **status**: unassigned -- accepted - **assigned_to**: Anders Bjornerstedt - **Version**: 4.6 -- 4.7 - **Milestone**: future -- 4.7-Tentative - **Comment**: This enahcnement can be used bot has a basis for solving the AMF problem descibed in #1105 and also as a starting point for #1261. --- ** [tickets:#1107] IMM: Provide an admin-operation for aborting all non-critical CCBs** **Status:** accepted **Milestone:** 4.7-Tentative **Created:** Thu Sep 18, 2014 06:33 AM UTC by Anders Bjornerstedt **Last Updated:** Tue Mar 03, 2015 01:14 PM UTC **Owner:** Anders Bjornerstedt This is related to ticket #1105: http://sourceforge.net/p/opensaf/tickets/1105/ The AMF needs to be able to force the immsv to abort all non critical CCBs in certain situations. The prime example is an si-swap or failover where there is an on going (non critical) CCB that has modified AMF data. The new active (and the new standby applier) can not attach as OIs as long as there is an open CCB operating on the data that the OI/applier is registered/registering to monitor. This new admin-operation can be used either automatically by the AMF, or manually by the operator. The autmatic use by the AMF will be a separate enhancement dependent on this one. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #1304 FAILED_OPERATION is not returned in case of response timeout from OI callback
- **Comment**: I think I understand this problem better now. The problem occurs if the om-client is not on the same processor as the immnd-coord. The IMMND that is elected the coordinator is the only one executing the periodic cleanTheBasement cleanup function. This function among other things checks for timeout on oi-ccb-callbacks. When it detects timeout it broadcasts an abort-ccb for that such a ccb over fevs. For some reason the FAILED_OPERATION then only reaches the om client if the om-client is colocated with the IMMND coord (at SC1 or SC2). The problem can be reproduced by executing 'immoitest 2 29'. If it is executed on a payload, the test fails. If it is executed on the SC where the immnd coord resides (same as where the immpbed process resides, whichis forked by the immnd coord, then the test succeeds. --- ** [tickets:#1304] FAILED_OPERATION is not returned in case of response timeout from OI callback** **Status:** assigned **Milestone:** 4.6.1 **Created:** Mon Apr 06, 2015 10:36 AM UTC by Sirisha Alla **Last Updated:** Fri Apr 10, 2015 07:53 AM UTC **Owner:** Neelakanta Reddy The issue is seen on cs6377(46 FC Tag). According to the fix of #57, failed operation is returned in case of timeout on response from OI. But timeout is being returned. IMMA Trace: Apr 6 15:31:37.931007 imma [7642:imma_om_api.c:1597] ccb_object_create_common Apr 6 15:31:37.931031 imma [7642:imma_om_api.c:1863] TR attr:attrName1 Apr 6 15:31:37.934663 imma [7642:imma_proc.c:1346] TR ** Event type:15 Apr 6 15:31:37.934700 imma [7642:imma_proc.c:1142] TR Posted IMMA_CALLBACK_OI_CCB_CREATE for ccb 2 Apr 6 15:31:37.934712 imma [7642:imma_db.c:0209] imma_oi_ccb_record_add Apr 6 15:31:37.934720 imma [7642:imma_db.c:0187] imma_oi_ccb_record_find Apr 6 15:31:37.934727 imma [7642:imma_db.c:0196] TR Record for ccbid:0x2 handle:330002030f client:0x89adf0 NOT found Apr 6 15:31:37.934735 imma [7642:imma_db.c:0198] imma_oi_ccb_record_find Apr 6 15:31:37.934740 imma [7642:imma_db.c:0244] TR Record for ccbid:0x2 handle:330002030f client:0x89adf0 opCount:0 added Apr 6 15:31:37.934744 imma [7642:imma_db.c:0245] imma_oi_ccb_record_add Apr 6 15:31:37.934748 imma [7642:imma_proc.c:1239] imma_proc_free_pointers Apr 6 15:31:37.934754 imma [7642:imma_proc.c:1332] imma_proc_free_pointers Apr 6 15:31:37.934774 imma [7642:imma_db.c:0187] imma_oi_ccb_record_find Apr 6 15:31:37.934779 imma [7642:imma_db.c:0194] TR Record for ccbid:0x2 handle:330002030f client:0x89adf0 found Apr 6 15:31:37.934784 imma [7642:imma_db.c:0198] imma_oi_ccb_record_find Apr 6 15:31:37.934788 imma [7642:imma_proc.c:1914] imma_process_callback_info Apr 6 15:31:37.934793 imma [7642:imma_proc.c:2233] TR Ccb-object-create callback Apr 6 15:31:37.934797 imma [7642:imma_db.c:0187] imma_oi_ccb_record_find Apr 6 15:31:37.934801 imma [7642:imma_db.c:0194] TR Record for ccbid:0x2 handle:330002030f client:0x89adf0 found Apr 6 15:31:37.934804 imma [7642:imma_db.c:0198] imma_oi_ccb_record_find Apr 6 15:31:37.934813 imma [7642:imma_proc.c:2336] TR ccb-object-create make the callback Apr 6 15:31:43.889216 imma [7642:imma_proc.c:1346] TR ** Event type:20 Apr 6 15:31:43.889296 imma [7642:imma_proc.c:0957] TR Posted IMMA_CALLBACK_OI_CCB_ABORT for ccb 2 Apr 6 15:31:43.889327 imma [7642:imma_db.c:0302] imma_oi_ccb_record_abort Apr 6 15:31:43.889349 imma [7642:imma_db.c:0187] imma_oi_ccb_record_find Apr 6 15:31:43.889857 imma [7642:imma_db.c:0194] TR Record for ccbid:0x2 handle:330002030f client:0x89adf0 found Apr 6 15:31:43.889888 imma [7642:imma_db.c:0198] imma_oi_ccb_record_find Apr 6 15:31:43.889909 imma [7642:imma_db.c:0313] imma_oi_ccb_record_abort Apr 6 15:31:43.889928 imma [7642:imma_proc.c:0960] T2 CCB-ABORT-UC: oi_ccb_record for 2 aborted Apr 6 15:31:43.889950 imma [7642:imma_proc.c:1239] imma_proc_free_pointers Apr 6 15:31:43.889970 imma [7642:imma_proc.c:1332] imma_proc_free_pointers Apr 6 15:31:47.941573 imma [7642:imma_om_api.c:1961] TR objectCreate send RETURNED:5 Apr 6 15:31:47.941671 imma [7642:imma_om_api.c:2092] ccb_object_create_common Apr 6 15:31:49.950709 imma [7642:imma_proc.c:2396] TR ccb-object-create callback returned RC:1 IMMND Trace: Apr 6 15:31:37.934582 osafimmnd [7422:immnd_evt.c:5978] T2 MAKING OI-IMPLEMENTER OBJ CREATE upcall towards agent Apr 6 15:31:37.935214 osafimmnd [7422:immnd_evt.c:6064] immnd_evt_proc_object_create Apr 6 15:31:37.935231 osafimmnd [7422:immnd_evt.c:8658] dequeue_outgoing Apr 6 15:31:37.935236 osafimmnd [7422:immnd_evt.c:8664] TR Pending replies:0 space:16 out list?:(nil) Apr 6 15:31:37.935241 osafimmnd [7422:immnd_evt.c:8693] dequeue_outgoing Apr 6 15:31:37.935244 osafimmnd [7422:immnd_evt.c:8777] immnd_evt_proc_fevs_rcv Apr 6 15:31:38.607788 osafimmnd [7422:immnd_proc.c:1637] T5 tmout:1000 ste:10 ME:24 RE:24 crd:0 rim:KEEP_REPO 4.3A:1 2Pbe:0 VetA/B: 1/0 othsc:0/0 Apr 6 15:31:43.632884 osafimmnd [7422:immnd_proc.c:1637] T5 tmout:1000 ste:10
[tickets] [opensaf:tickets] #131 LOG: LOG files not written with UTC time
Cannot be fixed because of backwards compatibility. Will however be solved when enhancement [#593] is implemented --- ** [tickets:#131] LOG: LOG files not written with UTC time** **Status:** unassigned **Milestone:** future **Created:** Mon May 13, 2013 10:03 AM UTC by elunlen **Last Updated:** Mon Aug 18, 2014 08:49 AM UTC **Owner:** nobody AIS-CPROG states that: A timestamp is represented in an SaTimeT data item as the number of positive nanoseconds elapsed since 00:00:00 UTC, 1 Jan 1970. Today log records are written in localized time. The accompanying .cfg file does not state timezone and/or daylight savings. This for example makes it nearly impossible to correlate log files from network nodes in different time zones. Other special purpose log streams might also suffer from lack of UTC. Migrated from devel.opensaf.org #3137 --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #142 LOG: Enabling/disabling logsvc traces by sending the USR1 signal is not working
- **status**: unassigned -- invalid - **assigned_to**: elunlen -- nobody - **Comment**: Does work now. See also [#785] --- ** [tickets:#142] LOG: Enabling/disabling logsvc traces by sending the USR1 signal is not working** **Status:** invalid **Milestone:** future **Created:** Mon May 13, 2013 11:04 AM UTC by elunlen **Last Updated:** Mon May 13, 2013 11:04 AM UTC **Owner:** nobody Enabled the logging by uncommenting the tarce line in the logd.conf Now tracing is enabled . If i send the USR1 signal to the osaflogd process any number of times , the tracing is not being disabled . Migrated from devel.opensaf.org #2280 --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #154 LOG: Add support for LOG file full actions WRAP and HALT
- **assigned_to**: elunlen -- nobody - **Type**: defect -- enhancement - **Comment**: Not a defect, Changed to enhancement --- ** [tickets:#154] LOG: Add support for LOG file full actions WRAP and HALT** **Status:** unassigned **Milestone:** future **Created:** Mon May 13, 2013 12:00 PM UTC by elunlen **Last Updated:** Wed May 15, 2013 09:49 AM UTC **Owner:** nobody Migrated from devel.opensaf.org #276 --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #134 LOG: Application is able to change the log file full action of the streams even though they are not implemented
- **status**: unassigned -- duplicate - **assigned_to**: elunlen -- nobody - **Comment**: See [#784] --- ** [tickets:#134] LOG: Application is able to change the log file full action of the streams even though they are not implemented** **Status:** duplicate **Milestone:** future **Created:** Mon May 13, 2013 10:22 AM UTC by elunlen **Last Updated:** Mon May 13, 2013 10:23 AM UTC **Owner:** nobody Currently only SA_LOG_FILE_FULL_ACTION_ROTATE is supported in the Implementation . But from immcfg i am able to change the LogFullAction value of the streams to HALT and WRAP . So with this even though the configuration shows that the full action is HALT or WRAP actually ROTATE if being done . So while configuring this to other than ROTATE a NOT_SUPPORTED ERROR should be raised instead of changing the value. Migrated from devel.opensaf.org #2279 --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #142 LOG: Enabling/disabling logsvc traces by sending the USR1 signal is not working
- **status**: invalid -- duplicate --- ** [tickets:#142] LOG: Enabling/disabling logsvc traces by sending the USR1 signal is not working** **Status:** duplicate **Milestone:** future **Created:** Mon May 13, 2013 11:04 AM UTC by elunlen **Last Updated:** Tue Apr 14, 2015 02:29 PM UTC **Owner:** nobody Enabled the logging by uncommenting the tarce line in the logd.conf Now tracing is enabled . If i send the USR1 signal to the osaflogd process any number of times , the tracing is not being disabled . Migrated from devel.opensaf.org #2280 --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] #142 LOG: Enabling/disabling logsvc traces by sending the USR1 signal is not working
See [#785] --- ** [tickets:#142] LOG: Enabling/disabling logsvc traces by sending the USR1 signal is not working** **Status:** duplicate **Milestone:** future **Created:** Mon May 13, 2013 11:04 AM UTC by elunlen **Last Updated:** Tue Apr 14, 2015 02:31 PM UTC **Owner:** nobody Enabled the logging by uncommenting the tarce line in the logd.conf Now tracing is enabled . If i send the USR1 signal to the osaflogd process any number of times , the tracing is not being disabled . Migrated from devel.opensaf.org #2280 --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
[tickets] [opensaf:tickets] Re: #1312 AMF: NodeFailover during SiSwap leaves SG UnStable
Hi Praveen,
I'm trying to reproduce #309 also. At the time fault happens during standby
assignment that escalated to nodeFailover, the SU on the other node has already
done active assignment. So I see the code inside if
(all_assignments_done(a_susi-su)) { always runs
-
/* the SI relationships to the SU is quiesced assigned
and the
* other SU is being modified to Active. If this
* SU admin is shutdown change to LOCK. If this SU
switch state
* is true change to false. Remove the SU from
operation list.
* Add that SU to the operation list . Change state to
* SG_realign state. Free all the SI assignments to
this SU.
*/
if (all_assignments_done(a_susi-su)) {
/* Since Act assignment is completely done, so
we don't expect any response from Act su. */
avd_sg_su_oper_list_del(cb, su, false);
su-delete_all_susis();
su-set_su_switch(AVSV_SI_TOGGLE_STABLE);
m_AVD_SET_SG_FSM(cb, (su-sg_of_su),
AVD_SG_FSM_STABLE);
/*As sg is stable, screen for si dependencies
and take action on whole sg*/
avd_sidep_update_si_dep_state_for_all_sis(su-sg_of_su);
avd_sidep_sg_take_action(su-sg_of_su);
} else {
--
If I understand correctly, the active su assignment on the other node must be
done before amfd starts sending standby assignment to the quiesced su. Can you
share the steps to reproduce #309?
Thanks,
Minh
---
** [tickets:#1312] AMF: NodeFailover during SiSwap leaves SG UnStable**
**Status:** assigned
**Milestone:** 4.4.2
**Created:** Fri Apr 10, 2015 10:57 AM UTC by Minh Hon Chau
**Last Updated:** Tue Apr 14, 2015 11:20 AM UTC
**Owner:** Minh Hon Chau
* Configuration:
2 2N SU1, SU2 hosted in SCs
1 sponsored SI (AGENT) and some dependent SIs (MTZ, ACA, CQH, AFD, HDF, NSF,
SGS, CLH, DBO)
Only one componentRestart will escalate to nodeFailover
* Steps and analysis
All SIs are assigned ACTIVE to SU1, STANDBY to SU2
1) Swap SI safSi=AFD,safApp=TEST_APP
Apr 10 11:00:49 SC-1 osafamfd[491]: NO safSi=AFD,safApp=TEST_APP Swap initiated
2) Swap 2N SI will lead to SU switch over
Apr 10 11:00:49 SC-1 osafamfnd[500]: NO Assigning 'safSi=ACA,safApp=TEST_APP'
QUIESCED to 'safSu=SU1,safSg=TEST_SG_2N,safApp=TEST_APP'
Apr 10 11:00:49 SC-1 osafamfnd[500]: NO Assigned 'safSi=ACA,safApp=TEST_APP'
QUIESCED to 'safSu=SU1,safSg=TEST_SG_2N,safApp=TEST_APP'
...
Apr 10 11:00:49 SC-1 osafamfnd[500]: NO Assigning 'safSi=AGENT,safApp=TEST_APP'
QUIESCED to 'safSu=SU1,safSg=TEST_SG_2N,safApp=TEST_APP'
Apr 10 11:00:49 SC-1 osafamfnd[500]: NO Assigned 'safSi=AGENT,safApp=TEST_APP'
QUIESCED to 'safSu=SU1,safSg=TEST_SG_2N,safApp=TEST_APP'
3) Assign sponsor SI ACTIVE to SU2
Apr 10 11:00:49 SC-2 osafamfnd[488]: NO Assigning 'safSi=AGENT,safApp=TEST_APP'
ACTIVE to 'safSu=SU2,safSg=TEST_SG_2N,safApp=TEST_APP'
(But AGENT in SC-2 has not responded to AMFND)
4) Binary of CQH is corrupted after QUIESCED response to AMF , escalate to
nodeFailover
Apr 10 11:00:50 SC-1 osafamfnd[500]: NO
'safComp=CQH,safSu=SU1,safSg=TEST_SG_2N,safApp=TEST_APP' recovery action
escalated from 'componentRestart' to 'nodeFailover'
Apr 10 11:00:50 SC-1 osafamfnd[500]: NO
'safComp=CQH,safSu=SU1,safSg=TEST_SG_2N,safApp=TEST_APP' faulted due to
'avaDown' : Recovery is 'nodeFailover'
5) SC-1 is going reboot, SC-2 becomes ACTIVE
Apr 10 11:00:50 SC-2 osafamfd[479]: NO FAILOVER StandBy -- Active
6) AMFD-SC2 starts node_failover procedure
Apr 10 11:00:50.731489 osafamfd [479:ndproc.cc:0923] avd_node_failover:
'safAmfNode=SC-1,safAmfCluster=myAmfCluster'
...
Apr 10 11:00:50.737048 osafamfd [479:sg_nored_fsm.cc:0793] node_fail:
safSu=SC-1,safSg=NoRed,safApp=OpenSAF, sg_fsm_state=0
Apr 10 11:00:50.745536 osafamfd [479:sg_2n_fsm.cc:3262] node_fail:
'safSu=SC-1,safSg=2N,safApp=OpenSAF', 0
Apr 10 11:00:50.748579 osafamfd [479:sg_2n_fsm.cc:3262] node_fail:
'safSu=SU1,safSg=TEST_SG_2N,safApp=TEST_APP', 2
7) During running node_fail_su_oper for TEST_SG_2N (due to swap), SG state set
to STABLE
Apr 10 11:00:50.748584 osafamfd [479:sg_2n_fsm.cc:2865] node_fail_su_oper
...
Apr 10 11:00:50.749197 osafamfd [479:sg.cc:1635] TR
safSg=TEST_SG_2N,safApp=TEST_APP sg_fsm_state 2 = 0
...
Apr 10 11:00:50.749217 osafamfd [479:sg_2n_fsm.cc:3099] node_fail_su_oper
8) Now in SC-2, AGENT responded to AMFND for ACTIVE csiSetCallback, AMFD
receives this su_si event from AMFND.
But SG is STABLE, and no operation for su_si modify (act:5)
Apr 10 11:00:59.280465 osafamfnd [488:susm.cc:0954] NO Assigned
'safSi=AGENT,safApp=TEST_APP' ACTIVE
[tickets] [opensaf:tickets] #785 Sending USR2 signal to logd is not resulting in the expected behaviour
I think this ticket requires a documentation update. pkill -USR2 osaflogd in the README needs to be corrected since it does not work. --- ** [tickets:#785] Sending USR2 signal to logd is not resulting in the expected behaviour ** **Status:** invalid **Milestone:** future **Created:** Fri Feb 14, 2014 06:10 AM UTC by manu **Last Updated:** Tue Apr 14, 2015 01:40 PM UTC **Owner:** nobody Execution of the following command on the controller node does not lead to any trace file as mentioned in the logsv README pkill -USR2 osaflogd However kill -12 `pgrep osaflogd` worked. The README needs to be updated accordingly. --- Sent from sourceforge.net because opensaf-tickets@lists.sourceforge.net is subscribed to https://sourceforge.net/p/opensaf/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.-- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF___ Opensaf-tickets mailing list Opensaf-tickets@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
