- **status**: assigned --> accepted
- **Comment**:
Spec sections related to surestart (recovery):
1))3.2.2.1 Presence State (Component):
A component is restarted by the Availability Management Framework in the
context of
error recovery and repair actions (for details, see Section 3.11) or in the
context of a
restart administrative operation (for details, see Section 9.4.7). Restarting a
component
means first terminating it and then instantiating it again (see Section
3.11.1.2).
Two different actions shall be undertaken by the Availability Management
Framework
regarding the component service instances assigned to a component when the
component
restart is needed:
• Keep the component service instances assigned to the component while the
component is restarted. This action is typically performed when it is faster to
restart the component than to reassign the component service instances to
another component. In this case, the presence state of the component is set to
restarting while the component is being terminated and until it is instantiated
again (or a failure occurs). Internally, in this particular scenario, the
Availability
Management Framework withdraws and reassigns exactly the same HA state on
behalf of all component service instances to the component as was assigned to
the component for various component service instances before the restart
procedure,
without evaluating the various criteria that the Availability Management
Framework would normally assess before making such an assignment.
• Reassign the component service instances currently assigned to the component
to another component before terminating/instantiating the component. In this
case, the presence state of the component is not set to restarting but
transitions
through the other presence state values (typically in the absence of failures:
terminating,
uninstantiated, instantiating, and then instantiated) as the component
is terminated and instantiated again.
The choice between these two policies is based on the
saAmfCompDisableRestart configuration attribute of each component (see the
SaAmfComp object class in Section 8.13.2).
2)3.8.2 Dependencies Among Components:
As has been said previously, the instantiation level is only applicable during
service
unit instantiation and termination. As restarting a service unit means
terminating the
service unit and instantiating it again, the instantiation level also applies
when restarting
a service unit. If single components within a service unit are restarted, the
instan-tiation level does not cause components with a higher level to be also
subject to a restart. The instantiation level is, above all, a means to limit
the load on the system during the instantiation process.
3)3.11.1.2 Restart:
During a restart because of a failure, a component remains enabled, and its
readiness
state may or may not change according to changes in its presence state (as
described in Section 3.2.2.1), which in turn determines whether its component
service
instances must be removed (refer to Section 3.2.2.3).
Restarting a service unit is achieved by the following actions:
• First, all components in the service unit are terminated in the order
dictated by
their instantiation-levels.
• In a second step, all components in the service unit are instantiated in the
order
dictated by their instantiation-levels.
During this restart procedure, the components follow their relevant state
transition
(see Section 3.2.2.1), which affects the presence state of the service unit (see
Section 3.2.1.1) and, consequently, its readiness state (see Section 3.2.1.4),
which in
turn determines the service instance assignments. If a service unit contains
only
restartable components, that is, the saAmfCompDisableRestart configuration
attribute of all the components is set to SA_FALSE (see the SaAmfComp object
class
in Section 8.13.2), the service unit remains in the in-service readiness state
during
the restart. As a consequence, its service instance assignments remain intact.
Conclusion:
For su restart recovery two cases will arise:
1)saAmfCompDisableRestart is false for all components in SU:
In this case surestart recovery will involve two steps:
a) First, all components in the SU are terminated in the order dictated by
their instantiation-levels.
b) In a second step, all components in the SU are instantiated in the order
dictated by their instantiation-levels.
Also if the components have assignments, same assignments will be reassigned to
the respective components after successful restart of SU. In this case, only
restarting state of the component will be observed.
2)saAmfCompDisableRestart is true for atleast one component in SU:
In this case, SU will start terminating the components honoring instantiation
level in reverse order. During this process, AMF will take care of reassignment
of CSIs assign to the component with this flag true. Such a component will
undergo transition through terminating, uninstantiated, instantiating, and then
instantiated state.Since a component will be protecting CSIs of any given
redundancy model, the process of reassignment depends upon the redundancy model
characteristics.
---
** [tickets:#315] SU restart not according to spec**
**Status:** accepted
**Milestone:** 4.5.2
**Created:** Fri May 24, 2013 08:35 AM UTC by Nagendra Kumar
**Last Updated:** Fri Apr 17, 2015 05:26 AM UTC
**Owner:** Praveen
Migrated from http://devel.opensaf.org/ticket/3061
First issue:
=====================
When testing http://devel.opensaf.org/ticket/3056 I found the problem that SU
restart does not follow the instantiation level as supposed to:
spec 3.8.2
"Within a service unit, the Availability Management Framework terminates the
pre-instantiable components according to the configured instantiation level.
All pre-instantiable components with the same instantiation level are
terminated by the Avail-
ability Management Framework in parallel. Pre-instantiable components of a
given level are only terminated by the Availability Management Framework when
all pre-instantiable components with a higher instantiation level have been
terminated.
As has been said previously, the instantiation level is only applicable during
service unit instantiation and termination. As restarting a service unit means
terminating the
service unit and instantiating it again, the instantiation level also applies
when restart-ing a service unit."
It is obvious from the code in avnd_su_pres_inst_surestart_hdler():
/*
•If pi su, pick the first pi comp & trigger it's FSM with RestartEv?. */
if (m_AVND_SU_IS_PREINSTANTIABLE(su)) {
TRACE("PI SU:'%s'",su->name.value);
for (curr_comp =
m_AVND_COMP_FROM_SU_DLL_NODE_GET(m_NCS_DBLIST_FIND_FIRST(&su->comp_list));
should pick the last component since this list is sorted by the instantiation
level.
Second issue:
================
3.11.1.2:
"Restarting a service unit is achieved by the following actions:
• First, all components in the service unit are terminated in the order
dictated by their instantiation-levels.
• In a second step, all components in the service unit are instantiated
in the order dictated by their instantiation-levels."
That is not the case today since each component is restarted (not terminated
and instantiated)
---
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.------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
