- **status**: accepted --> review
- **Comment**:
For unlock-in and lock-in operation AMF follows comp instantiation order.
During OpenSAF shutdown, AMF first removes the assignments from components
honoring SI/CSI dependencies. After removal of assignments, AMF launches
cleanup of all the components abruptly and simultaneously.
It is documented in the PR doc in section:
"
2.2.7 Ordered System Shutdown
2.2.7.1 Problem
When a system is shutdown (using for example the shutdown command), AMF needs
to stop all components under its control. Pre OpenSAF 4.2.1 this has been done
by an unordered component cleanup script execution.
If components and the services they provide has dependencies to each other, it
can cause problems to safely shutdown a system. Consider for example if one
component provides the service of mounting a file system and other components
uses this file system. If the shutdown is performed without ordering, the file
system can not be cleanly unmounted.
The AMF specification does not provide guidance to the question in what order
AMF should shutdown services/components?
2.2.7.2 Solution
In the AMF B.04 specification it is stated that "the rank of an SI is now
global to the cluster" and "the rank of the SI on which other SIs depend must
not be lower than the ranks of the dependent SIs".
Leveraging on that, AMF can decide which Service Instance to start removing.
That is the SI with the lowest rank (highest number) is removed first. By
removed it means that for sa-aware components, the CSI Remove Callback is
executed. For non-sa-aware components, the terminate commands is executed.
Within each SI, CSIs are removed in reversed order of their dependencies.
After all CSIs has been removed, component cleanup scripts are executed.
"
---
** [tickets:#337] amf: After controller failover, component termination order
was improper.**
**Status:** review
**Milestone:** 4.7-Tentative
**Created:** Mon May 27, 2013 05:37 AM UTC by Praveen
**Last Updated:** Thu Apr 02, 2015 04:48 AM UTC
**Owner:** Praveen
Migrated from http://devel.opensaf.org/ticket/2167.
After controller failover, component termination order was improper.
Steps followed:-
1. Runtime configured 2N model with 2 SUs in lock-instantiation state and
components without saAmfCompInstantiationLevel.
Each SU contains 3 components.
2. Now modified the saAmfCompInstantiationLevel as shown below:-
SU1_COMP1 = 1, SU1_COMP2 = 2, SU1_COMP3 = 3
SU2_COMP1 = 3, SU2_COMP2 = 2, SU2_COMP3 =1
3. Runtime unlock-in and unlock of each SUs.
SU1 was on PL-3 as active and SU2 was on SC-1 as standby
4. Initiated controller failover (reboot SC-1)
5. Expected Uninstantiated order for SU2 should be COMP1 -> COMP2 -> then COMP3.
but observed that it was coming as COMP3 -> COMP2 -> then COMP1, which is wrong.
However the instantiation order was proper.
Snippet of amfd logs of SC-2 (new active)
=================================
Sep 30 13:59:08.264349 osafamfd [6428:avd_comp.c:0085] >>
avd_comp_pres_state_set:
'safComp=Norm3,safSu=d_2n_2,safSg=SG_d_2n,safApp=2nApp' INSTANTIATED =>
UNINSTANTIATED
Sep 30 13:59:08.267403 osafamfd [6428:avd_comp.c:0085] >>
avd_comp_pres_state_set:
'safComp=Norm2,safSu=d_2n_2,safSg=SG_d_2n,safApp=2nApp' INSTANTIATED =>
UNINSTANTIATED
Sep 30 13:59:08.270512 osafamfd [6428:avd_comp.c:0085] >>
avd_comp_pres_state_set:
'safComp=Norm1,safSu=d_2n_2,safSg=SG_d_2n,safApp=2nApp' INSTANTIATED =>
UNINSTANTIATED
Sep 30 13:59:38.519157 osafamfd [6428:avd_comp.c:0085] >>
avd_comp_pres_state_set:
'safComp=Norm3,safSu=d_2n_2,safSg=SG_d_2n,safApp=2nApp' UNINSTANTIATED =>
INSTANTIATING
Sep 30 13:59:38.714064 osafamfd [6428:avd_comp.c:0085] >>
avd_comp_pres_state_set:
'safComp=Norm3,safSu=d_2n_2,safSg=SG_d_2n,safApp=2nApp' INSTANTIATING =>
INSTANTIATED
Sep 30 13:59:38.727753 osafamfd [6428:avd_comp.c:0085] >>
avd_comp_pres_state_set:
'safComp=Norm2,safSu=d_2n_2,safSg=SG_d_2n,safApp=2nApp' UNINSTANTIATED =>
INSTANTIATING
Sep 30 13:59:38.785638 osafamfd [6428:avd_comp.c:0085] >>
avd_comp_pres_state_set:
'safComp=Norm2,safSu=d_2n_2,safSg=SG_d_2n,safApp=2nApp' INSTANTIATING =>
INSTANTIATED
Sep 30 13:59:38.798887 osafamfd [6428:avd_comp.c:0085] >>
avd_comp_pres_state_set:
'safComp=Norm1,safSu=d_2n_2,safSg=SG_d_2n,safApp=2nApp' UNINSTANTIATED =>
INSTANTIATING
Sep 30 13:59:38.857310 osafamfd [6428:avd_comp.c:0085] >>
avd_comp_pres_state_set:
'safComp=Norm1,safSu=d_2n_2,safSg=SG_d_2n,safApp=2nApp' INSTANTIATING =>
INSTANTIATED
immlist safComp=Norm1,safSu=d_2n_1,safSg=SG_d_2n,safApp=2nApp -a
saAmfCompInstantiationLevel
saAmfCompInstantiationLevel=1
immlist safComp=Norm2,safSu=d_2n_1,safSg=SG_d_2n,safApp=2nApp -a
saAmfCompInstantiationLevel
saAmfCompInstantiationLevel=2
immlist safComp=Norm3,safSu=d_2n_1,safSg=SG_d_2n,safApp=2nApp -a
saAmfCompInstantiationLevel
saAmfCompInstantiationLevel=3
immlist safComp=Norm1,safSu=d_2n_2,safSg=SG_d_2n,safApp=2nApp -a
saAmfCompInstantiationLevel
saAmfCompInstantiationLevel=3
immlist safComp=Norm2,safSu=d_2n_2,safSg=SG_d_2n,safApp=2nApp -a
saAmfCompInstantiationLevel
saAmfCompInstantiationLevel=2
immlist safComp=Norm3,safSu=d_2n_2,safSg=SG_d_2n,safApp=2nApp -a
saAmfCompInstantiationLevel
saAmfCompInstantiationLevel=1
---
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.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Opensaf-tickets mailing list
Opensaf-tickets@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
