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 
Oct 18 17:07:11.873007 osafamfd [16148:imma_oi_api.c:2786] >> 
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 
Oct 18 17:07:11.873033 osafamfd [16148:imma_oi_api.c:2892] TR 
Oct 18 17:07:11.873039 osafamfd [16148:imma_oi_api.c:2892] TR 
Oct 18 17:07:11.873232 osafamfd [16148:imma_oi_api.c:3063] << 
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 
Oct 18 17:07:19.892514 osafamfd [16148:imma_oi_api.c:2786] >> 
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 
Oct 18 17:07:19.892573 osafamfd [16148:imma_oi_api.c:2892] TR 
Oct 18 17:07:19.893515 osafamfd [16148:imma_oi_api.c:3063] << 
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: 

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
    6)After this UNLOCK-IN and UNLOCK operation on SG was successful but SU 
remained in LOCK_IN state.
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 



** [tickets:#2009] AMF: App Si is moving to UNASSIGNED state after middleware 

**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

Reply via email to