Hi Gary Configuration should be handled in a separate section in the document(s) There should be a general description for how legacy behavior is handled that is always the same also if new configuration parameters are added in the future. The general rules are that legacy behavior shall be expected if: - No configuration object exist - The object exist but the configuration attribute is missing (may happen in the future when a new attribute is added) - The attribute value is empty or invalid
It is easier to add configuration attributes in the future if a table (or similar) is created describing each attribute: Example. Name Possible values and their meaning General comments For this attribute it could be valuable to include some information about the SMF dependency Thanks Lennart > -----Original Message----- > From: Gary Lee [mailto:[email protected]] > Sent: den 4 maj 2017 04:56 > To: Alex Jones <[email protected]> > Cc: [email protected] > Subject: Re: [devel] [PATCH 1/1] doc: update general and AMF readme files > [#2435] > > Hi > > In that case, they should be adding the IMM changes and specifying enabled > in the upgrade campaign. > > Gary > > > On 4 May 2017, at 12:10 pm, Alex Jones <[email protected]> > 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 ------------------------------------------------------------------------------ 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
