Hi! The question here I think is what should happen if this new configuration object doesn't exist. I think it is too dangerous to enable a new feature that changes legacy behaviour in this case, because someone could have forgotten to add this new object (or be unaware of the need to add such an object), or problems can happen during the upgrade when the object has not yet been created. If we are serious about going one-track, then we must ensure that upgrading is always 100% safe.
My suggestion is that for new OpenSAF installations, we can provide an AMF configuration object that by default enables this feature. But if the object doesn't exist we should provide legacy behaviour. regards, Anders Widell On 05/03/2017 04:24 PM, Alex Jones 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
