Analysis:
1)Node lock
Sep 4 11:58:47.209780 osafamfd [3482:node.cc:1042] >> node_admin_op_cb:
910533066753, 'safAmfNode=SC-
1,safAmfCluster=myAmfCluster', 2
Sep 4 11:58:47.209794 osafamfd [3482:node.cc:0783] >>
avd_node_admin_lock_unlock_shutdown: safAmfNode=SC-
1,safAmfCluster=myAmfCluster
Sep 4 11:58:47.209802 osafamfd [3482:node.cc:0674] >> node_admin_state_set:
safAmfNode=SC-1,safAmfCluster=myAmfCluster
AdmState UNLOCKED => LOCKED
2) After giving quiesced assignments to all the SIs in SU1 on node:2010f, AMF
starts failover
by giving active assginment for SI1 and SI5 to SU2 on node:2020f
Sep 4 11:58:47.746354 osafamfd [3482:siass.cc:0517] >> avd_susi_mod_send: SI
'safSi=TWONSI1,safApp=TWONAPP', SU
'safSu=SU2,safSg=SGONE,safApp=TWONAPP' ha_state:1
Sep 4 11:58:47.751463 osafamfd [3482:siass.cc:0517] >> avd_susi_mod_send: SI
'safSi=TWONSI5,safApp=TWONAPP', SU
'safSu=SU2,safSg=SGONE,safApp=TWONAPP' ha_state:1
Also AMFD marks SI2,SI3 and SI4 dep state as FAILOVER_UNDER_PROGRESS.
3) During this time, continuous faults in Su2 leads to su-failover. But AMFD
gets susi success for
SI1 and SI5:
Sep 4 11:58:49.334577 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:172, node:2020f, act:5,
'safSu=SU2,safSg=SGONE,safApp=TWONAPP', 'safSi=TWONSI1,safApp=TWONAPP', ha:1,
err:1, single:0
AMFD sends active for SI2 to SU2.
Sep 4 11:58:49.396129 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:176, node:2020f, act:5,
'safSu=SU2,safSg=SGONE,safApp=TWONAPP', 'safSi=TWONSI5,safApp=TWONAPP', ha:1,
err:1, single:0
4)AMFD gets su-failover request from AMFND
Sep 4 11:58:49.401742 osafamfd [3482:sgproc.cc:0468] >> avd_su_oper_state_evh:
id:178, node:2020f,
'safSu=SU2,safSg=SGONE,safApp=TWONAPP' state:2
AMFD sends delete to SU2:
Sep 4 11:58:49.414567 osafamfd [3482:sgproc.cc:2041] >> avd_sg_su_si_del_snd:
'safSu=SU1,safSg=SGONE,safApp=TWONAPP'
Sep 4
and deletes SUSI of SU2. Also SU5 is instantiated:
5)AMFD gets delete response for SU1:
Sep 4 11:58:49.976558 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:173, node:2010f, act:4,
'safSu=SU1,safSg=SGONE,safApp=TWONAPP', '', ha:3, err:1, single:0
It deletes all the SUSIs.
After this AMFD looks for new assignments and updated the si_dep states
Sep 4 11:58:49.983599 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI1,safApp=TWONAPP' si_dep_state ASSIGNED =>
NO_DEPENDENCY
Sep 4 11:58:49.983891 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI2,safApp=TWONAPP' si_dep_state ASSIGNED =>
SPONSOR_UNASSIGNED.
Sep 4 11:58:49.984235 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI3,safApp=TWONAPP' si_dep_state
FAILOVER_UNDER_PROGRESS => READY_TO_UNASSIGN
Sep 4 11:58:49.984523 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI3,safApp=TWONAPP' si_dep_state READY_TO_UNASSIGN =>
SPONSOR_UNASSIGNED
Sep 4 11:58:49.984776 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI4,safApp=TWONAPP' si_dep_state FAILOVER_UNDER_PROGRESS
=> READY_TO_UNASSIGN
Sep 4 11:58:49.985068 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI4,safApp=TWONAPP' si_dep_state READY_TO_UNASSIGN =>
SPONSOR_UNASSIGNED
After this new SUSIs are created in SU3 for SI1 and SI5.
Sep 4 11:58:49.985330 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU3,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI1,safApp=TWONAPP' state=1
Sep 4 11:58:49.991605 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU3,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI5,safApp=TWONAPP' state=1
6)Faults in SU3 also leads to sufailver but AMFD gets susi success for SI1 and
SI5:
Sep 4 11:58:53.799471 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:109, node:2030f, act:2,
'safSu=SU3,safSg=SGONE,safApp=TWONAPP', 'safSi=TWONSI1,safApp=TWONAPP', ha:1,
err:1, single:0
Sep 4 11:58:53.802374 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:110, node:2030f, act:2,
'safSu=SU3,safSg=SGONE,safApp=TWONAPP', 'safSi=TWONSI5,safApp=TWONAPP', ha:1,
err:1, single:0
Here AMFD updates, dep state of SI1
Sep 4 11:58:53.804538 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI1,safApp=TWONAPP' si_dep_state NO_DEPENDENCY =>
ASSIGNED
Sep 4 11:58:53.804884 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI2,safApp=TWONAPP' si_dep_state SPONSOR_UNASSIGNED =>
READY_TO_ASSIGN
Sep 4 11:58:53.805482 osafamfd [3482:si_dep.cc:2217] TR sponsor
si:'safSi=TWONSI3,safApp=TWONAPP', dep
state:'SPONSOR_UNASSIGNED'
and it creates SUSI for SI2 in SU3
:
Sep 4 11:58:53.805724 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU3,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI2,safApp=TWONAPP' state=1
Problem #1015: These SUSI are wronlgy created because of #1015. Here SUSI
success event before the su-failover
request is wrongly creating SUSIs in SU3.
7) Now AMFD gets su-failover request for SU3:
Sep 4 11:58:53.829641 osafamfd [3482:sgproc.cc:0468] >> avd_su_oper_state_evh:
id:113, node:2030f,
'safSu=SU3,safSg=SGONE,safApp=TWONAPP' state:2
AMFD deletes SUSIs in SU3:
Sep 4 11:58:53.835977 osafamfd [3482:su.cc:1871] >> delete_all_susis:
'safSu=SU3,safSg=SGONE,safApp=TWONAPP'
Again AMFD updates the SI dep states:
Sep 4 11:58:53.848218 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI1,safApp=TWONAPP' si_dep_state ASSIGNED =>
NO_DEPENDENCY
Sep 4 11:58:53.848757 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI2,safApp=TWONAPP' si_dep_state READY_TO_ASSIGN =>
SPONSOR_UNASSIGNED
Sep 4 11:58:53.849430 osafamfd [3482:si_dep.cc:2217] TR sponsor
si:'safSi=TWONSI3,safApp=TWONAPP', dep
state:'SPONSOR_UNASSIGNED'
Creation of SUSIs in SU4 for SI1 and SI5:
Sep 4 11:58:53.849616 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU4,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI1,safApp=TWONAPP' state=1
Sep 4 11:58:53.855811 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU4,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI5,safApp=TWONAPP' state=1
SUSIs are deleted in SU3.
8) Faults in SU4 leads to sufailover but AMFD gets susi success for SI1 and SI5:
Sep 4 11:58:54.513459 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:124, node:2040f, act:2,
'safSu=SU4,safSg=SGONE,safApp=TWONAPP', 'safSi=TWONSI1,safApp=TWONAPP', ha:1,
err:1, single:0
Sep 4 11:58:54.518958 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:125, node:2040f, act:2,
'safSu=SU4,safSg=SGONE,safApp=TWONAPP', 'safSi=TWONSI5,safApp=TWONAPP', ha:1,
err:1, single:0
AMFD updates dep state of SIs:
Sep 4 11:58:54.521819 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI1,safApp=TWONAPP' si_dep_state NO_DEPENDENCY =>
ASSIGNED
Sep 4 11:58:54.522482 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI2,safApp=TWONAPP' si_dep_state SPONSOR_UNASSIGNED =>
READY_TO_ASSIGN
Sep 4 11:58:54.523859 osafamfd [3482:si_dep.cc:2217] TR sponsor
si:'safSi=TWONSI3,safApp=TWONAPP', dep
state:'SPONSOR_UNASSIGNED'
Creation of SUSis in SU4:
Sep 4 11:58:54.524484 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU4,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI2,safApp=TWONAPP' state=1
Problem #1015: These SUSI are wronlgy created because of #1015. Here SUSI
success event before the su-failover
request is wrongly creating SUSIs in SU4.
9)AMFD gets su-failover request for SU4:
Sep 4 11:58:54.569849 osafamfd [3482:sgproc.cc:0468] >> avd_su_oper_state_evh:
id:129, node:2040f,
'safSu=SU4,safSg=SGONE,safApp=TWONAPP' state:2
AMFD deletes all SUSI in SU4
Sep 4 11:58:54.581158 osafamfd [3482:su.cc:1871] >> delete_all_susis:
'safSu=SU4,safSg=SGONE,safApp=TWONAPP'
AMFD updates SI dep states:
Sep 4 11:58:54.596497 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI1,safApp=TWONAPP' si_dep_state ASSIGNED =>
NO_DEPENDENCY
Sep 4 11:58:54.596902 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI2,safApp=TWONAPP' si_dep_state READY_TO_ASSIGN =>
SPONSOR_UNASSIGNED
AGAIN this lead to creation of SUSIs in SU5 for SI1 and SI5:
Sep 4 11:58:54.598168 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU5,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI1,safApp=TWONAPP' state=1
Sep 4 11:58:54.607877 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU5,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI5,safApp=TWONAPP' state=1
10) Faults in SU5 leads to SU-failover but AMFD gets susi success for SI1 and
SI5:
Sep 4 11:58:59.592520 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:144, node:2040f, act:2,
'safSu=SU5,safSg=SGONE,safApp=TWONAPP', 'safSi=TWONSI1,safApp=TWONAPP', ha:1,
err:1, single:0
Sep 4 11:58:59.595063 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:145, node:2040f, act:2,
'safSu=SU5,safSg=SGONE,safApp=TWONAPP', 'safSi=TWONSI5,safApp=TWONAPP', ha:1,
err:1, single:0
AMFD updates si deps states:
Sep 4 11:58:59.596696 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI1,safApp=TWONAPP' si_dep_state NO_DEPENDENCY =>
ASSIGNED
Sep 4 11:58:59.597177 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI2,safApp=TWONAPP' si_dep_state SPONSOR_UNASSIGNED =>
READY_TO_ASSIGN
Creation of SUSIs in SU5:
Sep 4 11:58:59.598252 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU5,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI2,safApp=TWONAPP' state=1
Problem #1015: These SUSI are wronlgy created because of #1015. Here SUSI
success event before the su-failover
request is wrongly creating SUSIs in SU5.
11) AMFD gets su-failover request from AMFND for Su5:
Sep 4 11:58:59.673485 osafamfd [3482:sgproc.cc:0468] >>
avd_su_oper_state_evh: id:150, node:2040f,
'safSu=SU5,safSg=SGONE,safApp=TWONAPP' state:2
Deletion of SUSIs in SU5:
Sep 4 11:58:59.680854 osafamfd [3482:su.cc:1871] >> delete_all_susis:
'safSu=SU5,safSg=SGONE,safApp=TWONAPP'
updation of SI dep states:
Sep 4 11:58:59.701858 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI1,safApp=TWONAPP' si_dep_state ASSIGNED =>
NO_DEPENDENCY
Sep 4 11:58:59.702399 osafamfd [3482:si_dep.cc:0202] TR
'safSi=TWONSI2,safApp=TWONAPP' si_dep_state READY_TO_ASSIGN =>
SPONSOR_UNASSIGNED
Since no more SUs are there for instantiation SG becomes stable now.
Sep 4 11:58:59.701031 osafamfd [3482:sg.cc:1611] TR safSg=SGONE,safApp=TWONAPP
sg_fsm_state 1 => 0
12) After this AMFD receives unlock operation:
Sep 4 11:59:00.248478 osafamfd [3482:node.cc:1042] >> node_admin_op_cb:
970662608905, 'safAmfNode=SC-
1,safAmfCluster=myAmfCluster', 1
Sep 4 11:59:00.248522 osafamfd [3482:node.cc:0783] >>
avd_node_admin_lock_unlock_shutdown: safAmfNode=SC-
1,safAmfCluster=myAmfCluster
Sep 4 11:59:00.248567 osafamfd [3482:node.cc:0674] >> node_admin_state_set:
safAmfNode=SC-1,safAmfCluster=myAmfCluster
AdmState LOCKED => UNLOCKED
SUSI are created in SU1 for SI1 and SI5:
Sep 4 11:59:00.256391 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU1,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI1,safApp=TWONAPP' state=1
Sep 4 11:59:00.262474 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU1,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI5,safApp=TWONAPP' state=1
13)Fault in SU1 leads to su-failover and AMFD gets susi success for SI1 and SI5:
Sep 4 11:59:03.883839 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:189, node:2010f, act:2,
'safSu=SU1,safSg=SGONE,safApp=TWONAPP', 'safSi=TWONSI1,safApp=TWONAPP', ha:1,
err:1, single:0
Sep 4 11:59:03.885654 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:190, node:2010f, act:2,
'safSu=SU1,safSg=SGONE,safApp=TWONAPP', 'safSi=TWONSI5,safApp=TWONAPP', ha:1,
err:1, single:0
AFMD updates si dep states as in the case of SU3-SU5 and then it creates SUSIs
for SI2 in SU1:
Sep 4 11:59:03.887369 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU1,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI2,safApp=TWONAPP' state=1
14) AMFD receives su-failover request for SU1:
Sep 4 11:59:03.910458 osafamfd [3482:sgproc.cc:0468] >>
avd_su_oper_state_evh: id:194, node:2010f,
'safSu=SU1,safSg=SGONE,safApp=TWONAPP' state:2
SUSIs are deleted for SU1:
Sep 4 11:59:03.918011 osafamfd [3482:su.cc:1871] >> delete_all_susis:
'safSu=SU1,safSg=SGONE,safApp=TWONAPP'
SG becomes stable and SI dep states are updated:
Sep 4 11:59:03.934531 osafamfd [3482:sg.cc:1611] TR safSg=SGONE,safApp=TWONAPP
sg_fsm_state 1 => 0
15) Since SgAutoRepair is not enabled no repair is performed for SU1-SU5:
16)AMFD gets auro repair request from admin:
Sep 4 12:00:38.152098 osafamfd [3482:su.cc:1104] >> su_admin_op_cb:
1099511627777, 'safSu=SU1,safSg=SGONE,safApp=TWONAPP', 9
Sep 4 12:00:38.152116 osafamfd [3482:su.cc:1055] >> repaired:
'safSu=SU1,safSg=SGONE,safApp=TWONAPP'
Creation of new SUSIs in SU1 for SI1 and SI5:
Sep 4 12:00:38.442774 osafamfd [3482:siass.cc:0157] >> avd_susi_create:
safSu=SU1,safSg=SGONE,safApp=TWONAPP
safSi=TWONSI1,safApp=TWONAPP state=1
Sep 4 12:00:38.453976 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU1,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI5,safApp=TWONAPP' state=1
17) AMFD gets SUSI success response for SI1 and SI5:
Sep 4 12:00:38.563883 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:216, node:2010f, act:2,
'safSu=SU1,safSg=SGONE,safApp=TWONAPP', 'safSi=TWONSI1,safApp=TWONAPP', ha:1,
err:1, single:0
Sep 4 12:00:38.627010 osafamfd [3482:sgproc.cc:0751] >> avd_su_si_assign_evh:
id:217, node:2010f, act:2,
'safSu=SU1,safSg=SGONE,safApp=TWONAPP', 'safSi=TWONSI5,safApp=TWONAPP', ha:1,
err:1, single:0
Creation of SUSIs for dependents as sponsor SI1 is assigned:
Sep 4 12:00:38.628683 osafamfd [3482:sgproc.cc:0070] >> avd_new_assgn_susi:
'safSu=SU1,safSg=SGONE,safApp=TWONAPP'
'safSi=TWONSI2,safApp=TWONAPP' state=1
Here AMFND does not responsd to AMFD for susi success because AMFND already
has record for SI2 in assigning state.
When AMFND sends susi success event to AMFD before the SU-failover request it
gets new assignment for SI2. Due to
this AMFND creates the record.
This is the same problem as in #1015.
But a small patch is required to reset su_cnt_admin_oper in node because for
node unlock operation this counter is incremented per susi at AMFD.
---
** [tickets:#1044] few si's are not assigned after su admin repair**
**Status:** unassigned
**Milestone:** 4.3.3
**Created:** Thu Sep 04, 2014 06:38 AM UTC by surender khetavath
**Last Updated:** Thu Sep 04, 2014 10:21 AM UTC
**Owner:** nobody
changeset : 5697
model : 2n
configuration : 1App,1SG,5SUs with 3comps each, 5SIs with 3CSIs each
si-si deps configured as SI1<-SI2<-SI3<-SI4.
SU1 is active, SU2 is standby.
SU1 is mapped to SC-1 and SU2 to SC-2,SU3 to PL-3 and SU4,5 to PL-4
saAmfSGAutoRepair=1(True)
SuFailover=1(True)
Test:
Node lock having active SU
in the new active assignments reject the new assignments
unlock the Node
due to continuous faults all the SUs move to disabled,Uninstantiated,OSS.
Now repairing the SU1 causes only few sis assigned and few unassigned as shown
below.
safSi=TWONSI2,safApp=TWONAPP
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=PARTIALLY_ASSIGNED(3)
safSi=TWONSI3,safApp=TWONAPP
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=UNASSIGNED(1)
safSi=TWONSI4,safApp=TWONAPP
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=UNASSIGNED(1)
safSi=TWONSI5,safApp=TWONAPP
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=PARTIALLY_ASSIGNED(3)
safSi=TWONSI1,safApp=TWONAPP
saAmfSIAdminState=UNLOCKED(1)
saAmfSIAssignmentState=PARTIALLY_ASSIGNED(3)
safSu=SU2,safSg=SGONE,safApp=TWONAPP
saAmfSUAdminState=UNLOCKED(1)
saAmfSUOperState=DISABLED(2)
saAmfSUPresenceState=UNINSTANTIATED(1)
saAmfSUReadinessState=OUT-OF-SERVICE(1)
safSu=SU3,safSg=SGONE,safApp=TWONAPP
saAmfSUAdminState=UNLOCKED(1)
saAmfSUOperState=DISABLED(2)
saAmfSUPresenceState=UNINSTANTIATED(1)
saAmfSUReadinessState=OUT-OF-SERVICE(1)
safSu=SU5,safSg=SGONE,safApp=TWONAPP
saAmfSUAdminState=UNLOCKED(1)
saAmfSUOperState=DISABLED(2)
saAmfSUPresenceState=UNINSTANTIATED(1)
saAmfSUReadinessState=OUT-OF-SERVICE(1)
safSu=SU1,safSg=SGONE,safApp=TWONAPP
saAmfSUAdminState=UNLOCKED(1)
saAmfSUOperState=ENABLED(1)
saAmfSUPresenceState=INSTANTIATED(3)
saAmfSUReadinessState=IN-SERVICE(2)
safSu=SU4,safSg=SGONE,safApp=TWONAPP
saAmfSUAdminState=UNLOCKED(1)
saAmfSUOperState=DISABLED(2)
saAmfSUPresenceState=UNINSTANTIATED(1)
saAmfSUReadinessState=OUT-OF-SERVICE(1)
safSISU=safSu=SU1\,safSg=SGONE\,safApp=TWONAPP,safSi=TWONSI5,safApp=TWONAPP
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU1\,safSg=SGONE\,safApp=TWONAPP,safSi=TWONSI1,safApp=TWONAPP
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU1\,safSg=SGONE\,safApp=TWONAPP,safSi=TWONSI2,safApp=TWONAPP
saAmfSISUHAState=ACTIVE(1)
safAmfNode=PL-3,safAmfCluster=myAmfCluster
saAmfNodeAdminState=UNLOCKED(1)
saAmfNodeOperState=ENABLED(1)
safAmfNode=PL-4,safAmfCluster=myAmfCluster
saAmfNodeAdminState=UNLOCKED(1)
saAmfNodeOperState=ENABLED(1)
safAmfNode=PL-5,safAmfCluster=myAmfCluster
saAmfNodeAdminState=UNLOCKED(1)
saAmfNodeOperState=ENABLED(1)
safAmfNode=SC-1,safAmfCluster=myAmfCluster
saAmfNodeAdminState=UNLOCKED(1)
saAmfNodeOperState=ENABLED(1)
safAmfNode=SC-2,safAmfCluster=myAmfCluster
saAmfNodeAdminState=UNLOCKED(1)
saAmfNodeOperState=ENABLED(1)
---
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.------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
