Hi Zoran,
Reviewed the patch.
Ack from me with one minor comment below.
BR,
Hung Nguyen - DEK Technologies
--------------------------------------------------------------------------------
From: Zoran Milinkovic zoran.milinko...@ericsson.com
Sent: Thursday, April 07, 2016 7:20PM
To: Neelakanta Reddy
reddy.neelaka...@oracle.com
Cc: Opensaf-devel
opensaf-devel@lists.sourceforge.net
Subject: [devel] [PATCH 1 of 1] imm: update README with IMM enhancements for
OpenSAF 5.0 [#1690]
osaf/services/saf/immsv/README | 93
++++++++++++++++++++++++++++++++++++++++++
1 files changed, 93 insertions(+), 0 deletions(-)
Update README with IMM enhancements
diff --git a/osaf/services/saf/immsv/README b/osaf/services/saf/immsv/README
--- a/osaf/services/saf/immsv/README
+++ b/osaf/services/saf/immsv/README
@@ -2748,6 +2748,99 @@ Return Values : SA_AIS_ERR_BUSY - The
Returncodes otherwise identical to saImmOmAccessorGet.
+
+SC Absence (5.0)
+===============================================
+https://sourceforge.net/p/opensaf/tickets/1625
+
+SC absence enhancement has the goal of increasing OpenSAFs resilience in
+the face of both active and standby SC going down. Both SCs being absent
+implies that all OpenSAF director services are absent indefinitely, until
+an SC is re-established. Prior to the SC absence enhancement, departure
+of both SCs always resulted in a cluster restart. With the SC Absence
+enhancement, payloads continue to provide reduced and limited service
+until an SC-active is re-established. For the IMM service, SC absence is
+configured by commenting in the environment variable IMMSV_SC_ABSENCE_ALLOWED.
+
+export IMMSV_SC_ABSENCE_ALLOWED=900
+
+Value of environment variable IMMSV_SC_ABSENCE_ALLOWED is stored in
+scAbsenceAllowed attribute in opensafImm=opensafImm,safApp=safImmService
+object. This value is used by AMF to restart the cluster if SC absence
+is longer than the value in scAbsenceAllowed attribute in seconds.
+
+Support for SC absence is incompatible with 2PBE. If both are configured
+then 2PBE will win and the SC absence feature will be ignored. An error
+message is printed in this case to the syslog at startup. Allowing SC absence
+feature is a configuration choice impacting all OpenSAF services, not just
+the IMM service. If it is to be allowed then it is not sufficient to only
+configure the IMM service for SC absence. The level of service that is
+provided during absent SC depends on the particular service. In the case
+of the IMM service, the service provided during SC absence is in essence
+only the reading of config data.
+
+
+Add attribute definition flag SA_IMM_ATTR_STRONG_DEFAULT (5.0)
+===============================================================
+https://sourceforge.net/p/opensaf/tickets/1425
+
+Having SA_IMM_ATTR_STRONG_DEFAULT flag on an attribute does not allow
+to set empty value to the attribute.
[Hung] I'm afraid that users will misunderstand this. They might expect
that IMM will return some error code when they do that. Actually, IMM
still allow to set those attributes to NULL when using ccbObjectModify
API, it's just that IMM automatically set default value to those
attributes. I think you can replace that line with this: " When there's
an attempt to set NULL value to (or to delete all values from)
attributes with this flag, default value will be set. The
SaImmAttrModificationT_2 will be changed to SA_IMM_ATTR_VALUES_REPLACE
with default value and sent to OI. "
+
+The default value is only effective for object creation, and not later
+in the life cycle of the object. This makes the default attribute value
+mechanism weaker than some users would like.
+With the new flag, during the object update, if empty value is set
+to the attribute, the default value will be set to the attribute.
+
+SA_IMM_ATTR_STRONG_DEFAULT flag can only be set on an attribute definition
+that includes default value.
+
+
+Canonicalize attributes presented by saImmOiCcbObjectModifyCallbackT_2 (5.0)
+============================================================================
+https://sourceforge.net/p/opensaf/tickets/801
+https://sourceforge.net/p/opensaf/tickets/1651
+
+For OIs or appliers receiving ccb-callbacks, the handling of the
modify-callback
+can be particularly complex. This is due to the modify callback being defined
+by SAF as faithfully presenting the same parameters as the originating
om-client
+parameters provided over the om-api.
+
+The object modify operation allows for modifications expressed as changes
+relative to the current state of attributes. This is of course acted on by
+the imm-server resulting in an after-image for the modified object.
+
+The callback to the OI or applier is currently of the same form, in general
+requiring the OI/applier to:
+ a) know the current state of the attributes of the object or do an for
+ appliers unsafe read
+ b) to correctly compute the transformation as defined by the imm-spec.
+Particularly the later is asking quite a lot for the average OI/applier
+implementer.
+
+Only for the "special applier" is the modify callback currently canonicalized
+to contain simply the replacement values, i.e. the after operation image.
+
+To simplify the task for OI's and appliers in handling modify callbacks,
+the modify-callback instead provides the after-modify-operation-image of
+the attributes. The new callback format containing just the replacement value
+resulting from the operation must be logically equivalent to the set of all
+before-image and operation variants resulting in this replacement value.
+
+
+Class and object applier set are on local node (5.0)
+====================================================
+https://sourceforge.net/p/opensaf/tickets/1535
+
+The enhancement makes object and class applier set info consistent per node.
+This means that applier set will bind objects and classes that have already
+been bound on the local node by the same applier name.
+
+Applier name continues to be shared between nodes, while object and class
+applier bindings are kept on the originating node.
+
+
----------------------------------------
DEPENDENCIES
============
------------------------------------------------------------------------------
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
------------------------------------------------------------------------------
_______________________________________________
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel
