Hi For a new install, the behaviour is on based on the 'default' AMF config files. For an upgrade, if the campaign is written based on the 'default' AMF config files, the behaviour is obviously the same (enabled).
Of course the user can choose to disable it (set enabled to 0) in the campaign to maintain BC. If the user does not add the config object at all, or doesn't set the attribute, the behaviour is off to maintain BC and avoid unexpected behaviour. I see this as the best compromise to maintain backwards compatibility, and to enable the repair restriction according to the spec. Gary > On 4 May 2017, at 12:24 am, Alex Jones <ajo...@genband.com> wrote: > > Hi Lennart, > > This was discussed at a recent TLC meeting, and it was agreed that any > behavior that is in the spec should be enabled by default because it is > in the spec. > > Alex > >> On 05/03/2017 10:21 AM, Lennart Lund wrote: >> ------------------------------------------------------------------------ >> NOTICE: This email was received from an EXTERNAL sender >> ------------------------------------------------------------------------ >> >> Hi Gary >> >> "For 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 is enabled by default, and can >> be disabled by setting ‘osafAmfRestrictAutoRepairEnable’ of the AMF >> general configuration object ‘amfConfig=1,safApp=safAmfService’ to ‘0’." >> >> My understanding was that this new behavior must be DISABLED by default. >> Is that not the case? The need of an upgrade of the IMM model and a new >> setting that must be handled in order to disable this is also NBC! >> Example use-case: A user that expects the legacy behavior upgrade to >> this new version but does not upgrade the IMM model (or maybe does that >> later during the upgrade). This user will now get the new NBC behavior >> and this may fail the upgrade. This is not acceptable. >> >> The new functionality shall not be enabled in the following situations: >> 1. >> No AMF configuration object exists >> 2. >> The configuration object exists but the osafAmfRestrictAutoRepairEnable >> is empty or has an invalid value (or in a generic case, a new attribute >> could be missing) >> 3. >> The osafAmfRestrictAutoRepairEnable=0 (disable) >> >> Note: >> The osafAmfRestrictAutoRepairEnable attribute (or any attribute that may >> be added in the future) should not be given a default value in the >> <class>.xml file meaning that if not configured the >> osafAmfRestrictAutoRepairEnable=<empty> meaning that new behavior is OFF >> (see 2.) >> >> Thanks >> Lennart >> >>> -----Original Message----- >>> From: Gary Lee [mailto:gary....@dektech.com.au] >>> Sent: den 3 maj 2017 13:22 >>> To: Anders Widell <anders.wid...@ericsson.com> >>> Cc: Hans Nordebäck <"hans.nordeback@"@ericsson.com>; opensaf- >>> de...@lists.sourceforge.net; Alex Jones <ajo...@genband.com>; Minh Hon >>> Chau <minh.c...@dektech.com.au> >>> Subject: Re: [devel] [PATCH 1/1] amfd: make auto repair restriction >>> configurable [#2435] >>> >>> Hi >>> >>> Yes, a draft of the changes is attached to the ticket awaiting feedback :) >>> >>> thanks >>> Gary >>> >>>> On 3 May 2017, at 9:01 pm, Anders Widell <anders.wid...@ericsson.com> >>> wrote: >>>> >>>> Hi! >>>> >>>> Will you update the documentation (README and PR doc) as well? Now >>> that we move towards continuous delivery we must be careful to keep the >>> documents up-to-date with the code at all times. >>>> >>>> thanks, >>>> >>>> Anders Widell >>>> >>>> >>>>> On 05/03/2017 06:37 AM, Gary Lee wrote: >>>>> Hi Alex >>>>> >>>>> The value is only used when the attribute is set to blank. I’ve >> changed the >>> comment to make it clearer. >>>>> >>>>> Thanks >>>>> Gary >>>>> >>>>> On 2/5/17, 11:15 pm, "Alex Jones" <ajo...@genband.com> wrote: >>>>> >>>>> Gary, >>>>> Shouldn't this be set to true here? >>>>> Alex >>>>>>> + while ((attr_mod = opdata->param.modify.attrMods[i++]) != >>> nullptr) { >>>>>>> + if (!strcmp(attr_mod->modAttr.attrName, >>>>>>> "osafAmfRestrictAutoRepairEnable")) { >>>>>>> + bool enabled = false; // default to disabled >>>>>>> + if (attr_mod->modType != SA_IMM_ATTR_VALUES_DELETE && >>>>>>> + attr_mod->modAttr.attrValues != nullptr) { >>>>>>> + enabled = >>>>>>> + static_cast<bool>(*((SaUint32T *)attr_mod- >>>> modAttr.attrValues[0])); >>>>>>> + } >>>>>>> + TRACE("osafAmfRestrictAutoRepairEnable changed to '%d'", >>> enabled); >>>>>>> + configuration->restrict_auto_repair(enabled); >>>>>>> + } >>>>>>> + } >>>>>>> + TRACE_LEAVE(); >>>>>>> +} >>>>> >>>>> >>>>> >>>>> >> ------------------------------------------------------------------------------ >>>>> 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 >>>>> Opensaf-devel@lists.sourceforge.net >> <mailto:Opensaf-devel@lists.sourceforge.net> >>>>> 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 >>> Opensaf-devel@lists.sourceforge.net >> <mailto:Opensaf-devel@lists.sourceforge.net> >>> 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 Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
