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
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
