---
 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

Reply via email to