The release notes shall always contain important information that you need to be aware of when upgrading to a new release, so I will mention this in the release notes for the next release. Of course, we have the same problem again that someone might not read the release notes carefully enough, but at least the problem only exists when upgrading from 5.2. It is easier to miss information from the release notes when upgrading from an older release.
regards, Anders Widell On 05/04/2017 04:10 AM, Alex Jones wrote: > One potential wrinkle I see with this.... > > The new AMF/SMF behavior is currently in 5.2. If someone does a > greenfield install of 5.2, and then does an upgrade with this new AMF > change in it, they lose the behavior. > > Is there a way we can tell if we are upgrading from 5.2 and enable the > behavior, but disable it in other cases? > > Alex > > ------------------------------------------------------------------------ > *From:* Gary Lee [[email protected]] > *Sent:* Wednesday, May 03, 2017 9:15 PM > *To:* [email protected]; [email protected]; > [email protected]; Alex Jones > *Cc:* [email protected]; Gary Lee > *Subject:* [PATCH 1/1] doc: update general and AMF readme files [#2435] > > ------------------------------------------------------------------------ > NOTICE: This email was received from an EXTERNAL sender > ------------------------------------------------------------------------ > > --- > README | 7 +++++-- > src/amf/README | 29 +++++++++++++++++++++++++++++ > 2 files changed, 34 insertions(+), 2 deletions(-) > > diff --git a/README b/README > index 27fbe24c2..56c050d10 100644 > --- a/README > +++ b/README > @@ -960,8 +960,11 @@ 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. > > 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/src/amf/README b/src/amf/README > index 0a94351a6..2c168041e 100644 > --- a/src/amf/README > +++ b/src/amf/README > @@ -150,6 +150,35 @@ 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’. > + > +Users upgrading from prior releases should add the class definition of > +'OpenSafAmfConfig' and object 'amfConfig=1,safApp=safAmfService' to > +IMM (see src/amf/config/amf_classes.xml and > src/amf/config/amf_objects.xml). > + > +Users that require the legacy auto-repair behaviour should set > +'osafAmfRestrictAutoRepairEnable' to '0' during the campInitAction > phase of > +the OpenSAF upgrade campaign. > + > +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. > + > 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
