Hi zoran, Ack with the following comments.
On Thursday 07 April 2016 05:50 PM, Zoran Milinkovic wrote: > 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 configured by uncommenting 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. > + > +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. > + SA_IMM_ATTR_STRONG_DEFAULT flag is supported when OM API registers with version A.02.17 or higher. > + > +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. > + Canonicalize attributes are presented by saImmOiCcbObjectModifyCallbackT_2 when IMM OI registers with version A.02.17 or higher . /Neel. > + > +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 > ============ ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/ gampad/clk?id=1444514301&iu=/ca-pub-7940484522588532 _______________________________________________ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
