A) Steps to reproduce the issue reported in "Discussion/Comment" section:
1)Bring two controllers up and bring up create_app.xml.
2)Lock and LOCK-in SU1.
3)Delete the only SI.
4)Stop active controller.
When standby becomes active controller, it tries to create SISU and CSICOMP in
IMM and it fails:
Oct 18 17:07:11.872982 osafamfd [16148:imm.cc:0142] >> exec: Create
safSi=AmfDemo,safApp=AmfDemo1
Oct 18 17:07:11.873007 osafamfd [16148:imma_oi_api.c:2786] >>
rt_object_create_common
Oct 18 17:07:11.873019 osafamfd [16148:imma_oi_api.c:2892] TR attr:safSISU
Oct 18 17:07:11.873026 osafamfd [16148:imma_oi_api.c:2892] TR
attr:saAmfSISUHAState
Oct 18 17:07:11.873033 osafamfd [16148:imma_oi_api.c:2892] TR
attr:saAmfSISUHAReadinessState
Oct 18 17:07:11.873039 osafamfd [16148:imma_oi_api.c:2892] TR
attr:osafAmfSISUFsmState
Oct 18 17:07:11.873232 osafamfd [16148:imma_oi_api.c:3063] <<
rt_object_create_common
Oct 18 17:07:11.873641 osafamfd [16148:imm.cc:0163] ER exec: create FAILED 12
Oct 18 17:07:19.892496 osafamfd [16148:imm.cc:0142] >> exec: Create
safCsi=AmfDemo,safSi=AmfDemo,safApp=AmfDemo1
Oct 18 17:07:19.892514 osafamfd [16148:imma_oi_api.c:2786] >>
rt_object_create_common
Oct 18 17:07:19.892536 osafamfd [16148:imma_oi_api.c:2892] TR attr:safCSIComp
Oct 18 17:07:19.892556 osafamfd [16148:imma_oi_api.c:2892] TR
attr:saAmfCSICompHAState
Oct 18 17:07:19.892573 osafamfd [16148:imma_oi_api.c:2892] TR
attr:saAmfCSICompHAReadinessState
Oct 18 17:07:19.893515 osafamfd [16148:imma_oi_api.c:3063] <<
rt_object_create_common
Oct 18 17:07:19.893611 osafamfd [16148:imm.cc:0163] ER exec: create FAILED 12
B) Steps to reproduce a related issue:
1)Bring up two controllers and bring up create_app.xml.
2)Lock and LOCK-in SU1.
3)Delete the app: immcfg -d safApp=AmfDemo1.
4) Now add configuration add_app.xml using "immcfg -f add_app.xml.
Configuration add_app.xml creates the same app as in create_app.xml with only
difference that SG is in lock-in state and SUs in unlocked state.
5)Stop active controller. When standby becomes active controller, amf-state
su shows wrong admin state of SU1:
safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1
saAmfSUAdminState=LOCKED-INSTANTIATION(3)
saAmfSUOperState=ENABLED(1)
saAmfSUPresenceState=UNINSTANTIATED(1)
saAmfSUReadinessState=OUT-OF-SERVICE(1)
But state is correct in AMF database. After dumping state from AMF:
dn: safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1
saAmfSUPreInstantiable: 1
saAmfSUOperState: ENABLED
saAmfSUAdminState: UNLOCKED
saAmfSuReadinessState: OUT_OF_SERVICE
saAmfSUPresenceState: UNINSTANTIATED
saAmfSUHostedByNode: safAmfNode=SC-2,safAmfCluster=myAmfCluster
saAmfSUNumCurrActiveSIs: 0
saAmfSUNumCurrStandbySIs: 0
saAmfSURestartCount: 0
term_state: 0
su_switch: 0
assigned_SIs:
6)After this UNLOCK-IN and UNLOCK operation on SG was successful but SU
remained in LOCK_IN state.
Analysis:
Standby controller maintains a job queue for SU, SiSU and COMPCSI class of size
200. In the job queue both old and new state of a object will be present. The
issue is not observed normally because standby will update correct state
eventually from old to new. In the above cases since object was deleted and
added with new state the issue was observed. One more possiblity (although
remote) is if standby after becoming active updates only older state and
reboots. In the case new state will not get updated and IMM will show wrong
state.
---
** [tickets:#2009] AMF: App Si is moving to UNASSIGNED state after middleware
failover**
**Status:** assigned
**Milestone:** 5.0.2
**Created:** Thu Sep 08, 2016 06:07 AM UTC by Srikanth R
**Last Updated:** Tue Sep 20, 2016 05:55 PM UTC
**Owner:** Praveen
Environment details
------------------
OS : Suse 64bit
Changeset : 7997 ( 5.1.FC)
Setup : 5 nodes ( 2 controllers and 3 payloads with headless feature enabled &
no PBE )
AMF Application : 2N model with SUs mapped on PL-3,PL-4 ( si-si deps enabled)
Summary :
------------------
Application SIs are moving to UNASSIGNED state after middleware failover.
Steps followed & Observed behaviour
------------------
-> Initially brought up AMF application (2n model) on two payloads.
-> All the SIs are fully assigned state and SUs are in INSERVICE state.
-> Performed middleware failover.
-> After standby became active controller, SIs moved to unassigned state. But
'amf-state siass' is showing proper output.
-> Application received CSI remove callbacks after locking the SUs
Expected behaviour
------------------
-> As no fault happened on the application, SIs should not move to UNASSIGNED
state for middleware failover.
---
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.------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
