According to the error log messages, AMF treats an "unstable" SG as a 
validation error:

~~~
Nov 10 03:20:03 SC-2-1 ABC: NOTICE: immcfg -a saAmfSIPrefActiveAssignments=2 
safSi=All-NWayActive,safApp=ABC returned error - saImmOmCcbApply FAILED: 
SA_AIS_ERR_FAILED_OPERATION (21)#012OI reports: IMM: Validation abort: 
Completed validation fails (ERR_BAD_OPERATION)#012OI reports: 
SG'safSg=NWayActive,safApp=ABC' is not stable (1)
~~~

This is not correct, since the "unstable" state is only temorary and the exact 
same operation could succeed at a later point when the target object is no 
longer "unstable". When a CCB fails due to an AMF entity being "ustable", it 
should be treated as a resource abort rather than a validation abort. I think 
you could return SA_AIS_ERR_NO_RESOURCES as suggested by Hung.


---

** [tickets:#2184] AMF: Return TRY_AGAIN if SG Fsm State is not STABLE**

**Status:** assigned
**Milestone:** 5.0.2
**Created:** Sat Nov 12, 2016 11:59 AM UTC by Minh Hon Chau
**Last Updated:** Tue Nov 22, 2016 11:04 AM UTC
**Owner:** Minh Hon Chau


We have AMFD code returning SA_AIS_ERR_TRY_AGAIN to IMM if SG fsm state is not 
STABLE, while other places are returning SA_AIS_ERR_BAD_OPERATION.
According to AMF spec, item 9.4:

"SA_AIS_ERR_TRY_AGAIN - The service cannot be provided at this time. The client
may retry later. This error generally should be returned when the requested 
action is
valid but not currently possible, probably because another operation is acting 
upon
the logical entity on which the administrative operation is invoked. Such an 
operation
can be another administrative operation or an error recovery initiated by the 
Availabil-
ity Management Framework."

9.4.2 SA_AMF_ADMIN_UNLOCK
SA_AIS_ERR_BAD_OPERATION - The operation was not successful because the tar-
get entity is in locked-instantiation administrative state.
9.4.3 SA_AMF_ADMIN_LOCK
SA_AIS_ERR_BAD_OPERATION - The operation was not successful because the tar-
get entity is in locked-instantiation administrative state.
... and so on

SA_AIS_ERR_BAD_OPERATION should be returned in case that operations are 
impossibly executable under a specific circumtance. 

One application has seen "immcfg -a saAmfSIPrefActiveAssignments" sometimes 
returning SA_AIS_ERR_FAILED_OPERATION while the SG is performing SUSI 
assignment, sometimes immcfg succeeds. 

Nov 10 03:20:03 SC-2-1 ABC: NOTICE: immcfg -a saAmfSIPrefActiveAssignments=2 
safSi=All-NWayActive,safApp=ABC returned error - saImmOmCcbApply FAILED: 
SA_AIS_ERR_FAILED_OPERATION (21)#012OI reports: IMM: Validation abort: 
Completed validation fails (ERR_BAD_OPERATION)#012OI reports: 
SG'safSg=NWayActive,safApp=ABC' is not stable (1)
…
Nov 10 03:20:03 SC-2-1 osafamfnd[12061]: NO 
'safSu=SC-1,safSg=NWayActive,safApp=ABC' Presence State INSTANTIATING => 
INSTANTIATED
Nov 10 03:20:03 SC-2-1 osafamfnd[12061]: NO Assigned 
'safSi=All-NWayActive,safApp=ABC' ACTIVE to 
'safSu=SC-1,safSg=NWayActive,safApp=ABC'

This ticket will change SA_AIS_ERR_BAD_OPERATION to SA_AIS_ERR_TRY_AGAIN in all 
other places where SG is not STABLE, so that application can try again until SG 
becomes STABLE (as it should be).


---

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

Reply via email to