Missed hg add command. Attaching README. Thanks, Praveen
On 04-Apr-16 1:02 PM, [email protected] wrote:
Contains information related to: -details of implementation. -changes at AMFD. -changes at AMFND. -changes at AMFA. ------------------------------------------------------------------------------ _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
/* -*- OpenSAF -*- * * (C) Copyright 2016 The OpenSAF Foundation * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY * or FITNESS FOR A PARTICULAR PURPOSE. This file and program are licensed * under the GNU Lesser General Public License Version 2.1, February 1999. * The complete license can be accessed from the following location: * http://opensource.org/licenses/lgpl-license.php * See the Copying file included with the OpenSAF distribution for full * licensing terms. * * Author(s): Oracle * */ General: ================================= Current AMF implementation conforms to B.04.01 spec version. No version of AMF spec talks about any feature, using which a user can pass a running component some information without loss of service. However, there is a class "SaAmfCSIAttribute" which can be used by to pass some information in the form of name values pair by configuring the object of this class for a CSI. When configured, CSI attribute information is passed to component whenever it is assigned some workload (CSI). AMF spec allows dynamic modification of CSI attribute values, but such a imformation is passed to the component only after removal of assignment. For OpenSAF release 5.0, enhancement ticket https://sourceforge.net/p/opensaf/tickets/1553/ is intended to provide this functionality of passing CSI attrbiute values to a running component whenever it is changed. Implementation Notes for "CSI Attribute Change Callback": ====================================================== As a part of \#1553, minor version (SAF) of AMF service is updated to 02 because of introduction of new saAmfInitialize_5() API, new callback structure SaAmfCallbacksT_5 and a new CSI Attribute Change callback OsafCsiAttributeChangeCallbackT. Also introduced a new attribute osafAmfCSICommunicateCsiAttributeChange in class SaAmfCSI. So highest supported version now becomes B.04.02. About the new resources at Agent: -OsafCsiAttributeChangeCallbackT This callback will be used to communicate runtime to a component, any change in the CSI attribute values for a CSI assigned to it. A component will register with this callback using new initialize API saAmfInitialize_5(). Callback Characteristics: -Argument: typedef void (*OsafCsiAttributeChangeCalbackT)( SaInvocationT invocation, const SaNameT *csiName, SaAmfCSIAttributeListT csiAttr); -After receving this callback, a component will have to respond to AMFND using saAmfResponse() API against invocation number. -Callback will be invoked in the context of registered process. -Callback is meant for SA-Aware component, PROXIED PI component and PROXIED NPI component. -Callback time out same as saAmfCompCSISetCallbackTimeout or saAmfCtDefCallbackTimeout. -SaAmfCallbacksT_5 (structure) typedef struct { SaAmfHealthcheckCallbackT saAmfHealthcheckCallback; SaAmfComponentTerminateCallbackT saAmfComponentTerminateCallback; SaAmfCSISetCallbackT saAmfCSISetCallback; SaAmfCSIRemoveCallbackT saAmfCSIRemoveCallback; SaAmfProtectionGroupTrackCallbackT_4 saAmfProtectionGroupTrackCallback; SaAmfProxiedComponentInstantiateCallbackT saAmfProxiedComponentInstantiateCallback; SaAmfProxiedComponentCleanupCallbackT saAmfProxiedComponentCleanupCallback; SaAmfContainedComponentInstantiateCallbackT saAmfContainedComponentInstantiateCallback; SaAmfContainedComponentCleanupCallbackT saAmfContainedComponentCleanupCallback; OsafCsiAttributeChangeCallbackT osafCsiAttributeChangeCallback; } SaAmfCallbacksT_5; This is new structure consisting of all B.04.01 callbacks and newly introduced OsafCsiAttributeChangeCallbackT. Using this along with saAmfInitialize_5() API a component can register for all AMF callbacks. -API SaAisErrorT saAmfInitialize_5( SaAmfHandleT *amfHandle, const SaAmfCallbacksT_5 *amfCallbacks, SaVersionT *version); Applicable return codes are same as valid for saAmfInitialize_4(). New API for initializing with AMF service for all callbacks including the new one. New saf version for this is B.04.02. A user will have to compulsory register OsafCsiAttributeChangeCallbackT callback along with other mandatory callbacks to initialize with AMF service using this API. -Attribute osafAmfCSICommunicateCsiAttributeChange in class SaAmfCSI. A NON Proxied NPI component neither registers with AMF nor it is registered via any Proxy component. AMF manages only Life Cycle of this component through CLC-CLI scripts. All CLC-CLI scripts are idempotents. For such a component, AMF passes name/value pairs of CSI as environment variables to each CLC-CLI command. If there is change in CSI attribute value for a CSI assigned to NON PROXIED NPI component, it will be passed to the component as environment variables by executing INSTANTIATED command provided osafAmfCSICommunicateCsiAttributeChange is marked true for the assigned CSI. Changes at AMFD (CSI Attribute Change Callback): =============================================== 1)Support for new attribute osafAmfCSICommunicateCsiAttributeChange in class SaAmfCSI. Dynamic modification of this attribute is supported. Default value will be 0. 2)New message AVSV_D2N_COMPCSI_ASSIGN_MSG from AMFD to AMFND for compcsi related information. As of now only CSI attribute list will be sent to AMFND. In future it can be used in the context of tickets like \#538 (TERM_FAILED state) and \#83. 3)Upon modification of CSI attribute value for a object of class "SaAmfCSIAttribute", AMFD will send a message to AMFND with new list. For a NON PROXIED NPI component, message will not be sent if osafAmfCSICommunicateCsiAttributeChange is false. For such a component, change will come into effect only when its SI is locked and unlocked or other such ways. 4)AMFD now also maintains MDS install version of all AMFNDs in std::map<SaClmNodeIdT, MDS_SVC_PVT_SUB_PART_VER> nds_mds_ver_db. It will be updated whenever AMFD gets MDS_UP and MDS_DOWN for AMFND. Using this AMFD can decide whether message is meant for particular AMFND much before encode callback given by AMFND. Changes at AMFND (CSI Attribute Change Callback): ================================================= 1)New internal AMF callback from AMFND to AMF agent corresponding to OsafCsiAttributeChangeCallbackT for giving modified CSI Attribute Name value pairs to component (AVSV_AMF_CSI_ATTR_CHANGE_PARAM). 2)AMFND processes AVSV_D2N_COMPCSI_ASSIGN_MSG from AMFD. Upong receving CSI attribute list, it updates its databae with modified information. If compoent has registered with new callback OsafCsiAttributeChangeCallbackT, then it will send this modification through internal callback AVSV_AMF_CSI_ATTR_CHANGE_PARAM to AMF agent. 3)AMFND now maintains MDS install version of AMF AGENTs in std::map<MDS_DEST, MDS_SVC_PVT_SUB_PART_VER> agent_mds_ver_db. It will be updated whenever AMFND gets MDS_UP and MDS_DOWN for AMF Agent. Using this AMFND can decide whether message is meant for particular Agent much before encode callback given by AMFND. 4)AMFND maintains now SAF version for each registered component. AMFND will get it from Agent thorugh existing component registeration message. Changes at AMF Agent (CSI Attribute Change Callback): ===================================================== 1)Because of different AMF callback struture correponding to each of B.01.01 B.04.01, introduced and internal callback structure OsafAmfCallbacksT. It consists of callback from each AMF version. Since callback for each intialization needs to be maintained internally in AVA_HDL_REC. With this internal structure, same handle can used interanlly for any initialization of AMF service. Here it is: typedef struct osaf_amf_cbk { SaAmfHealthcheckCallbackT saAmfHealthcheckCallback; SaAmfComponentTerminateCallbackT saAmfComponentTerminateCallback; SaAmfCSISetCallbackT saAmfCSISetCallback; SaAmfCSIRemoveCallbackT saAmfCSIRemoveCallback; SaAmfProtectionGroupTrackCallbackT saAmfProtectionGroupTrackCallback; SaAmfProtectionGroupTrackCallbackT_4 saAmfProtectionGroupTrackCallback_4; //Only in B.04.01 SaAmfProxiedComponentInstantiateCallbackT saAmfProxiedComponentInstantiateCallback; SaAmfProxiedComponentCleanupCallbackT saAmfProxiedComponentCleanupCallback; SaAmfContainedComponentInstantiateCallbackT saAmfContainedComponentInstantiateCallback; SaAmfContainedComponentCleanupCallbackT saAmfContainedComponentCleanupCallback; OsafCsiAttributeChangeCallbackT osafCsiAttributeChangeCallback; //OpenSAF implementation. } OsafAmfCallbacksT; Also added utility function to copy callbacks from AMF callbacks structure to this internal one. AMF agent will use OsafAmfCallbacksT internally instead of SaAmfCallbacksT_<#x>. 2)Implementation of saAmfInitialize_5() in ava_api.c. 3)Now saAmfRegister() also sends SAF version to AMFND. TODOs: (CSI Attribute Change Callback): ===================================================== 1)Fault handling when INSTANTIATED command for a Non Proxied NPI component fails. 2)Will raise one ticket related to existing memory leak issue when object of class "SaAmfCSIAttribute" is configured. 3)Writing a demo app for demonstrating this feature. 4)MDS version update for AMFD and AMFND is not required as it has been done in \#1620. It is required onlye once in a release. Testing: (CSI Attribute Change Callback): ===================================================== 1)Tested Amf demo app (CSI attribute class object configured) on two controller system. All these patches were present on both the controllers. On active controlelr Amf demo initializes with B.04.02 and register new callback. On standby controller Amf demo registers with B.01.01. When csi attribute value is modified component active controller got new callback: Apr 4 08:42:48 SC-1 amf_demo[21059]: =====CSI Attr Change====> Apr 4 08:42:48 SC-1 amf_demo[21059]: CSI----->:'safCsi=AmfDemo,safSi=AmfDemo,safApp=AmfDemo1' Apr 4 08:42:48 SC-1 amf_demo[21059]: CSIATTR--->: AmfDemo1, val--->: _amf Apr 4 08:42:48 SC-1 amf_demo[21059]: CSIATTR--->: AmfDemo1, val--->: AAAA Apr 4 08:42:48 SC-1 amf_demo[21059]: CSIATTR--->: AmfDemo1, val--->: BBBB Apr 4 08:42:48 SC-1 amf_demo[21059]: <================= On standby controller amfnd traces (callback not issued by AMFND as comp has not registered it): Apr 4 12:21:20.410631 osafamfnd [26780:su.cc:0976] >> avnd_evt_avd_compcsi_evh: 'safComp=AmfDemo,safSu=SU2,safSg=AmfDemo,safApp=AmfDemo1', 'safCsi=AmfDemo,safSi=AmfDemo,safApp=AmfDemo1', act:1 Apr 4 12:21:20.410640 osafamfnd [26780:su.cc:0910] TR Component version is not B.04.02 Apr 4 12:21:20.410645 osafamfnd [26780:su.cc:1009] << avnd_evt_avd_compcsi_evh: 1 2)As of now tested one +ve case for sa-ware component. 3)Patch may get updated for minor changes related to fault handling for all types for components. Continuing with the testing....
------------------------------------------------------------------------------
_______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
