Hi I will push this on Friday if there are no more comments.
Thanks Gary On 5/5/17, 2:06 pm, "Gary Lee" <[email protected]> wrote: --- README | 10 +++++-- samples/amf/OpenSafAmfConfig_Upgrade_5.2.xml | 25 +++++++++++++++++ src/amf/README | 40 +++++++++++++++++++++++++++- 3 files changed, 72 insertions(+), 3 deletions(-) create mode 100644 samples/amf/OpenSafAmfConfig_Upgrade_5.2.xml diff --git a/README b/README index 27fbe24c2..72f9abc3e 100644 --- a/README +++ b/README @@ -960,8 +960,14 @@ minimum version requirements of the following system components: When upgrading to OpenSAF 5.2.0 or later, be aware that SMF upgrade campaigns can behave differently compared to earlier OpenSAF releases in case of component -failures. This is because Section 4.2.1.3 of SMF spec A.01.02 was implemented in -OpenSAF 5.2.0. +failures. This is because Section 4.2.1.3 of SMF spec A.01.02 and +Section 3.11.1.4.2 of AMF spec B.04.01 are implemented in OpenSAF 5.2.0. +The attribute 'osafAmfRestrictAutoRepairEnable' in the new class +OpenSafAmfConfig allows this behaviour to be disabled. +Please see the AMF and SMF Programmer's References for more details. +The class schema and new AMF configuration object should be added +when upgrading from an older release of OpenSAF. An XML file containing +the changes can be found at samples/amf/OpenSafAmfConfig_Upgrade_5.2.xml After upgrading to OpenSAF 5.2.0, please review the setting of OSAF_CKPT_SHM_ALLOC_GUARANTEE in /etc/opensaf/ckptnd.conf. To avoid a diff --git a/samples/amf/OpenSafAmfConfig_Upgrade_5.2.xml b/samples/amf/OpenSafAmfConfig_Upgrade_5.2.xml new file mode 100644 index 000000000..2fdfd009d --- /dev/null +++ b/samples/amf/OpenSafAmfConfig_Upgrade_5.2.xml @@ -0,0 +1,25 @@ +<?xml version="1.0" encoding="utf-8"?> +<imm:IMM-contents xmlns:imm="http://www.saforum.org/IMMSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:noNamespaceSchemaLocation="SAI-AIS-IMM-XSD-A.02.13.xsd"> + <class name="OpenSafAmfConfig"> + <category>SA_CONFIG</category> + <rdn> + <name>amfConfig</name> + <type>SA_STRING_T</type> + <category>SA_CONFIG</category> + <flag>SA_INITIALIZED</flag> + </rdn> + <attr> + <name>osafAmfRestrictAutoRepairEnable</name> + <type>SA_UINT32_T</type> + <category>SA_CONFIG</category> + <flag>SA_WRITABLE</flag> + </attr> + </class> + <object class="OpenSafAmfConfig"> + <dn>amfConfig=1,safApp=safAmfService</dn> + <attr> + <name>osafAmfRestrictAutoRepairEnable</name> + <value>1</value> + </attr> + </object> +</imm:IMM-contents> diff --git a/src/amf/README b/src/amf/README index 0a94351a6..7885fc982 100644 --- a/src/amf/README +++ b/src/amf/README @@ -11,12 +11,30 @@ * See the Copying file included with the OpenSAF distribution for full * licensing terms. * - * Author(s): Oracle + * Author(s): Oracle, Ericsson * */ General: ================================= Current AMF implementation conforms to B.04.01 spec version. + +AMF behaviour can be changed through a configuration object 'amfConfig=1,safApp=safAmfService'. + +osafAmfRestrictAutoRepairEnable: 1 (enabled), 0 or blank (disabled) +------------------------------------------------------------------- +When set to 1, support for 'Restriction to Auto-Repair' is enabled as specified +in Section 3.11.1.4.2 of the AMF specification SAI-AIS-AMF-B.04.01. + +If 'Restrictions to Auto-Repair' is disabled, then the maintenance campaign +will not be sent in SU operational state change notifications. This means the +Software Management Framework (SMF) will not be able to detect asynchronous +failures of AMF entities (see Section 4.2.1.3 of the SMF specification for details). + +Note: if AMF cannot read 'osafAmfRestrictAutoRepairEnable' because it is missing +or set to blank, it will assume the legacy auto-repair behaviour is wanted to +maintain backwards compatibility. + + No version of AMF spec talks about any feature, using which a user can pass some information to a running component without loss of service. However, there is a class "SaAmfCSIAttribute" which can be used @@ -150,6 +168,26 @@ Changes at AMF Agent (CSI Attribute Change Callback): 2)Implementation of saAmfInitialize_5() in ava_api.c. 3)Now saAmfRegister() also sends SAF version to AMFND. +Changes in OpenSAF 5.2: +======================= + +Prior to OpenSAF 5.2, the attribute saAmfSUMaintenanceCampaign of the SaAmfSU +class was not used by AMF. + +In OpenSAF 5.2, enhancement ticket #2144 adds support for +'Restrictions to Auto-Repair' (Section 3.11.1.4.2 of the AMF specification +SAI-AIS-AMF-B.04.01). This support is configurable through +the attribute 'osafAmfRestrictAutoRepairEnable' of a new AMF general configuration +object 'amfConfig=1,safApp=safAmfService' + +The class schema and new AMF configuration object should be added +when upgrading from an older release of OpenSAF. An XML file containing +the changes can be found at samples/amf/OpenSafAmfConfig_Upgrade_5.2.xml + +Users that require the legacy auto-repair behaviour should set +'osafAmfRestrictAutoRepairEnable' to '0' during the campInitAction phase of +the OpenSAF upgrade campaign. + TODOs: (CSI Attribute Change Callback): ===================================================== 1)Invocation of INSTANTIATE command for a Non Proxied NPI component. -- 2.11.0 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
