- **Milestone**: 4.7.2 --> 5.0.2
---
** [tickets:#1919] amf: Improper lock operation sequence in NpM model.**
**Status:** unassigned
**Milestone:** 5.0.2
**Labels:** NpM
**Created:** Mon Jul 18, 2016 11:32 AM UTC by Praveen
**Last Updated:** Mon Jul 18, 2016 11:32 AM UTC
**Owner:** nobody
**Attachments:**
- [npm.tgz](https://sourceforge.net/p/opensaf/tickets/1919/attachment/npm.tgz)
(15.2 kB; application/x-compressed)
In Npm Model lock operation sequence is inconsistent with what is mentioned in
AMF spec section 10.5.
Here is the sequence of events based on AMF traces for lock operation on SU:
1) AMFD sends quiesced:
Jul 13 14:51:40.651539 osafamfd [10039:sgproc.cc:2231] >>
avd_sg_su_si_mod_snd: 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1', state 3
Jul 13 14:51:40.651547 osafamfd [10039:mbcsv_api.c:0773] >>
mbcsv_process_snd_ckpt_request: Sending checkpoint data to all STANDBY p
2) Quiesced respnse comes:
Jul 13 14:51:40.655170 osafamfd [10039:sgproc.cc:1051] >> avd_su_si_assign_evh:
id:101, node:2010f, act:5, 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1', '', ha:3,
err:1, single:0
3) Now AMFD sends active to standby SU and deletion to quiesced SU
simultaneously:
Jul 13 14:51:40.655335 osafamfd [10039:sg_npm_fsm.cc:2338] <<
avd_sg_get_curr_act_cnt: current Active SUs :0
Jul 13 14:51:40.655342 osafamfd [10039:sgproc.cc:2231] >> avd_sg_su_si_mod_snd:
'safSu=SU2,safSg=AmfDemo,safApp=AmfDemo1', state 1
Jul 13 14:51:40.655707 osafamfd [10039:sg_npm_fsm.cc:2455] <<
avd_sg_npm_stdbysu_role_change
Jul 13 14:51:40.655714 osafamfd [10039:sgproc.cc:2340] >> avd_sg_su_si_del_snd:
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13
4)Deletion should be sent after receiving successful active response from SU2.
Generally SUs are hosted on different nodes,so problem could not be noticed
easily. But hosting both the SUs on same node shows it clearly in syslog itself:
Jul 13 14:51:40 SC-1 osafamfnd[10049]: NO Assigning
'safSi=AmfDemo,safApp=AmfDemo1' QUIESCED to
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10268]: =====CSI SET====>
Jul 13 14:51:40 SC-1 amf_demo[10268]:
Comp---->:'safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10268]: CSI FLAG----->:SA_AMF_CSI_TARGET_ALL(4)
Jul 13 14:51:40 SC-1 amf_demo[10268]: HAState---->:Quiesced
Jul 13 14:51:40 SC-1 amf_demo[10268]: <================
Jul 13 14:51:40 SC-1 osafamfnd[10049]: NO Assigned
'safSi=AmfDemo,safApp=AmfDemo1' QUIESCED to
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 osafamfnd[10049]: NO Assigning
'safSi=AmfDemo,safApp=AmfDemo1' ACTIVE to
'safSu=SU2,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10290]: =====CSI SET====>
Jul 13 14:51:40 SC-1 amf_demo[10290]:
Comp---->:'safComp=AmfDemo,safSu=SU2,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10290]: CSI FLAG----->:SA_AMF_CSI_TARGET_ALL(4)
Jul 13 14:51:40 SC-1 amf_demo[10290]: HAState---->:Active
Jul 13 14:51:40 SC-1 amf_demo[10290]: transitionDescriptor:
SA_AMF_CSI_NEW_ASSIGN
Jul 13 14:51:40 SC-1 amf_demo[10290]: activeCompName:
Jul 13 14:51:40 SC-1 amf_demo[10290]: <================
Jul 13 14:51:40 SC-1 osafamfnd[10049]: NO Removing
'safSi=AmfDemo,safApp=AmfDemo1' from 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10268]: ========>CSI Remove=====>
Jul 13 14:51:40 SC-1 amf_demo[10268]:
Comp---->:'safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10268]: CSI FLAG ----------->:
SA_AMF_CSI_TARGET_ALL
Jul 13 14:51:40 SC-1 amf_demo[10268]: <=======================
Jul 13 14:51:40 SC-1 osafamfnd[10049]: NO Removed
'safSi=AmfDemo,safApp=AmfDemo1' from 'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Jul 13 14:51:40 SC-1 amf_demo[10268]: saAmfResponse after lopp- 1
Jul 13 14:51:41 SC-1 amf_demo[10290]: Waiting for the flag being set
Jul 13 14:51:41 SC-1 osafamfnd[10049]: NO Assigned
'safSi=AmfDemo,safApp=AmfDemo1' ACTIVE to
'safSu=SU2,safSg=AmfDemo,safApp=AmfDemo1'
So removal compelted in SU1 even before SU2 becomes active.
Valid for lock/shutdown operation on Node, SU and with #1454 it will be valid
for lock/shutdown on NG also. Will check for lock operatiion on SI.
Attached are traces and configuration.
---
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.
------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
