On page 74 for Prescence state of Component spec says, when a restartable
component is instantiated, it will move from restarting to Instantiated state.
Thus for a restartable SU, when last comp is started terminating, SU will move
to RESTARTING state. At this point of time all the component are in RESTARTING
state and SU is also in RESTARTING state. Now AMF will instantiate first
component and after successful instantiation this component will move to
INSTANTIATED state.
So now for marking the presence state of SU. AMF has following information:
-one component is in INSTANTIATED state.
-All the remaining component are in RESTARTING state waiting for instantiation.
If we refer to Page74 table and draw the state, AMF must mark the su
INSTANTIATED because only in this state components can be in RESTARTING state
with atleast one component in INSTANTIATED state.
Now two problem comes:
1) AMF has to send state change notification for presence state as SU is in
INSTANTIATED state.
If AMF sends it now then a user application must not assume that all
components are restarted when some of them are still in restarting state.
If AMF delays it then there will be time diffenrence when SU was marked
instantiated and the notification was sent.
2) same is the problem for repyling to IMM for the status of admin operation.
I think it is ok to delay both, notification and replying to IMM client, as
presence state of component and SU are not directly exposed to the
application.
---
** [tickets:#1518] AMF: SU presence state transition is not correct during
admin op restart**
**Status:** unassigned
**Milestone:** 4.5.2
**Created:** Tue Oct 06, 2015 07:41 AM UTC by Quyen Dao
**Last Updated:** Tue Oct 06, 2015 07:41 AM UTC
**Owner:** nobody
>From my observation, the su and component presence state transition is as
>below during admin su (with all restartable components) restart:
su: INSTANTIATED => RESTARTING => INSTANTIATING => INSTANTIATED
component: INSTANTIATED => RESTARTING => INSTANTIATED
In my opinion, the presence state transition of su should be the same as
component for this case:
INSTANTIATED => RESTARTING => INSTANTIATED
According to AIS-AMF-B.04.01-Table 5 Presence State of Components of a Service
Unit Page 74, if all components are RESTARTING, then SU should be RESTARTING
(not INSTANTIATING) as well.
**syslog for su presence state transition**
Oct 6 12:24:50 PL-3 osafamfnd[418]: NO Admin Restart request for
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Oct 6 12:24:50 PL-3 osafamfnd[418]: NO
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1' Presence State INSTANTIATED =>
RESTARTING
Oct 6 12:24:50 PL-3 amf_demo[757]: Terminating
Oct 6 12:24:50 PL-3 osafamfnd[418]: NO
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1' Presence State RESTARTING =>
INSTANTIATING
Oct 6 12:24:50 PL-3 amf_demo[985]:
'safComp=AmfDemo,safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1' started
Oct 6 12:24:50 PL-3 osafamfnd[418]: NO
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1' Presence State INSTANTIATING =>
INSTANTIATED
Oct 6 12:24:50 PL-3 osafamfnd[418]: NO Assigning
'safSi=AmfDemo,safApp=AmfDemo1' ACTIVE to
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
Oct 6 12:24:50 PL-3 amf_demo[985]: Registered with AMF and HC started
Oct 6 12:24:50 PL-3 amf_demo[985]: CSI Set - add
'safCsi=AmfDemo,safSi=AmfDemo,safApp=AmfDemo1' HAState Active
Oct 6 12:24:50 PL-3 osafamfnd[418]: NO Assigned
'safSi=AmfDemo,safApp=AmfDemo1' ACTIVE to
'safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1'
---
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
