Analysis:
On Sc-2:
1)Lock of SU2:
Sep 29 19:18:26.873563 osafamfd [29019:su.cc:1110] >> su_admin_op_cb:
3341484556289, 'safSu=SU2,safSg=SG,safApp=test2nApp', 2
Sep 29 19:18:26.873602 osafamfd [29019:su.cc:0897] >> lock:
'safSu=SU2,safSg=SG,safApp=test2nApp'
Sep 29 19:18:26.873614 osafamfd [29019:su.cc:0805] >> set_readiness_state:
'safSu=SU2,safSg=SG,safApp=test2nApp'
OUT_OF_SERVICE
Sep 29 19:18:26.889020 osafamfd [29019:sg_2n_fsm.cc:3789] TR act_found'0',
quisced_found'0', quiscing_found'0'
Sep 29 19:18:26.889024 osafamfd [29019:sg_2n_fsm.cc:3806] <<
avd_su_state_determine: state '2'
Sep 29 19:18:26.889028 osafamfd [29019:sgproc.cc:2066] >> avd_sg_su_si_del_snd:
'safSu=SU2,safSg=SG,safApp=test2nApp'
2)AMFD gets response for deletion:
Sep 29 19:18:27.218472 osafamfd [29019:sgproc.cc:0762] >> avd_su_si_assign_evh:
id:289, node:2040f, act:4,
'safSu=SU2,safSg=SG,safApp=test2nApp', '', ha:2, err:1, single:0
Sep 29 19:18:27.222317 osafamfd [29019:su.cc:1881] >> delete_all_susis:
'safSu=SU2,safSg=SG,safApp=test2nApp'
SG becomes stable
Sep 29 19:18:27.256629 osafamfd [29019:sg.cc:1613] TR safSg=SG,safApp=test2nApp
sg_fsm_state 1 => 0
Response to IMM successful:
Sep 29 19:18:27.258110 osafamfd [29019:imm.cc:1691] >>
avd_saImmOiAdminOperationResult: inv:3341484556289, res:1
Sep 29 19:18:27.258121 osafamfd [29019:imm.cc:1696] <<
avd_saImmOiAdminOperationResult
3) Now this amfd is killed, that time amfd was doing TR object update to imm.
This could not be completed as amfd was killed in between.
Sep 29 19:18:27.272037 osafamfd [29019:mbcsv_api.c:0868] <<
mbcsv_process_snd_ckpt_request: retval: 1
Sep 29 19:18:27.272507 osafamfd [29019:imm.cc:0305] >> execute
Sep 29 19:18:27.272528 osafamfd [29019:imm.cc:0144] >> exec: Update
'safComp=COMP49,safSu=SU2,safSg=SG,safApp=test2nApp'
saAmfCompReadinessState
Sep 29 19:18:27.272536 osafamfd [29019:imma_oi_api.c:2279] >>
saImmOiRtObjectUpdate_2
Sep 29 19:18:27.274673 osafamfd [29019:imma_oi_api.c:2554] <<
saImmOiRtObjectUpdate_2
Sep 29 19:18:27.274697 osafamfd [29019:imm.cc:0173] << exec
Sep 29 19:18:27.274703 osafamfd [29019:imm.cc:0309] << execute: 1
Sep 29 19:18:27.274883 osafamfd [29019:imm.cc:0305] >> execute
Sep 29 19:18:27.274919 osafamfd [29019:imm.cc:0144] >> exec: Update
'safComp=COMP50,safSu=SU2,safSg=SG,safApp=test2nApp'
saAmfCompReadinessState
Sep 29 19:18:27.274927 osafamfd [29019:imma_oi_api.c:2279] >>
saImmOiRtObjectUpdate_2
Sep 29 19:18:27.278576 osafamfd [29019:imma_oi_api.c:2554] <<
saImmOiRtObjectUpdate_2
Sep 29 19:18:27.278620 osafamfd [29019:imm.cc:0173] << exec
Sep 29 19:18:27.278642 osafamfd [29019:imm.cc:0309] << execute: 1
Sep 29 19:18:27.278655 osafamfd [29019:imm.cc:0305] >> execute
Sep 29 19:18:27.278662 osafamfd [29019:imm.cc:0144] >> exec: Update
'safSu=SU2,safSg=SG,safApp=test2nApp' saAmfSUAdminState
Sep 29 19:18:27.278670 osafamfd [29019:imma_oi_api.c:2279] >>
saImmOiRtObjectUpdate_2
Sep 29 19:20:01.867103 osafamfd [2860:main.cc:0464] >> initialize
Sep 29 19:20:01.901777 osafamfd [2860:ncs_main_pub.c:0223] TR
NCS:PROCESS_ID=2860
On SC-1:
1)It became active
Sep 29 19:18:58.012573 osafamfd [2348:role.cc:0251] >> avd_role_failover
Sep 29 19:18:58.012595 osafamfd [2348:role.cc:0252] NO FAILOVER StandBy -->
Active
Sep 29 19:18:58.012609 osafamfd [2348:mbcsv_api.c:0662] >>
mbcsv_process_chg_role_request: Change HA role for the checkpoint
2) Since on SC_2, SU2 has no SUSI as it is locked new active does not do
anything:
Sep 29 19:18:58.051060 osafamfd [2348:sgproc.cc:1698] <<
avd_node_down_mw_susi_failover
Sep 29 19:18:58.051067 osafamfd [2348:sgproc.cc:1716] >>
avd_node_down_appl_susi_failover: 'safAmfNode=SC-
2,safAmfCluster=myAmfCluster'
Sep 29 19:18:58.051076 osafamfd [2348:sgproc.cc:1791] <<
avd_node_down_appl_susi_failover
3)SC-1 receives lock-in operation for SU2:
Sep 29 19:19:46.357546 osafamfd [2348:su.cc:1110] >> su_admin_op_cb:
3354369458177, 'safSu=SU2,safSg=SG,safApp=test2nApp', 3
Sep 29 19:19:46.357600 osafamfd [2348:su.cc:0947] >> lock_instantiation:
'safSu=SU2,safSg=SG,safApp=test2nApp'
After SU2 becomes UNINSTANTIATED, AMF responds to IMM
Sep 29 19:19:46.793240 osafamfd [2348:su.cc:0745] >> set_pres_state:
'safSu=SU2,safSg=SG,safApp=test2nApp' TERMINATING =>
UNINSTANTIATED
Sep 29 19:19:46.793787 osafamfd [2348:ndproc.cc:0325] >>
su_admin_op_report_to_imm: (1) (3354369458177)
Sep 29 19:19:46.793791 osafamfd [2348:imm.cc:1691] >>
avd_saImmOiAdminOperationResult: inv:3354369458177, res:1
Sep 29 19:19:46.793796 osafamfd [2348:imm.cc:1696] <<
avd_saImmOiAdminOperationResult
Sep 29 19:19:46.793800 osafamfd [2348:ndproc.cc:0379] <<
su_admin_op_report_to_imm: (0)
Conclusions:
1)SG stable whith Su1 is active and SU is locked-in. So there is no problem
from funtionality perspective.
2) Since SC-2 was killed before performing RTobject update, a user will see
SUSIs for all the SIs and SU2 with
standby state.
3)This is known problem and require enhancement.
It is already maintained as a todo in AMF code amfd/sgproc.cc as:
/* Finish as many IMM jobs as possible because active
controller is rebooting.
TODO(Praveen): All the pending IMM related jobs should
be handled by the standby when it will become
active after controller fail-over.
TODO: There should be some flush method on the job queue.
*/
AvdJobDequeueResultT job_res = JOB_EXECUTED;
while (job_res == JOB_EXECUTED)
job_res = Fifo::execute(cb->immOiHandle);
---
** [tickets:#1141] si assignments are not removed after lock/lock-in of su with
failover**
**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Mon Sep 29, 2014 02:03 PM UTC by surender khetavath
**Last Updated:** Mon Sep 29, 2014 02:03 PM UTC
**Owner:** nobody
changeset : 5918
model : 2n
configuration:
1App,1SG,2SUs with 50comps each,50SIs with 1CSI each
bring up the application. lock SU and parallely kill amfd on active node
Here sc2 was active. PL-3 and PL-4 hosts SU1 & SU2 resp.
safSu=SU1,safSg=SG,safApp=test2nApp
saAmfSUAdminState=UNLOCKED(1)
saAmfSUOperState=ENABLED(1)
saAmfSUPresenceState=INSTANTIATED(3)
saAmfSUReadinessState=IN-SERVICE(2)
safSu=SU2,safSg=SG,safApp=test2nApp
saAmfSUAdminState=LOCKED-INSTANTIATION(3)
saAmfSUOperState=ENABLED(1)
saAmfSUPresenceState=UNINSTANTIATED(1)
saAmfSUReadinessState=OUT-OF-SERVICE(1)
safSi=SI1,safApp=test2nApp
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=FULLY_ASSIGNED(2)
safSi=SI2,safApp=test2nApp
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=FULLY_ASSIGNED(2)
safSi=SI3,safApp=test2nApp
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=FULLY_ASSIGNED(2)
safSi=SI4,safApp=test2nApp
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=FULLY_ASSIGNED(2)
.....
....
safSISU=safSu=SU1\,safSg=SG\,safApp=test2nApp,safSi=SI49,safApp=test2nApp
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU1\,safSg=SG\,safApp=test2nApp,safSi=SI50,safApp=test2nApp
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU2\,safSg=SG\,safApp=test2nApp,safSi=SI27,safApp=test2nApp
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SU2\,safSg=SG\,safApp=test2nApp,safSi=SI28,safApp=test2nApp
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SU2\,safSg=SG\,safApp=test2nApp,safSi=SI29,safApp=test2nApp
saAmfSISUHAState=STANDBY(2)
....
....
---
Sent from sourceforge.net because [email protected] 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.------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
