Hi Anders What's implemented is what you have suggested below. I think I have to make this clearer in the PR though.
Gary > On 4 May 2017, at 1:11 am, Anders Widell <anders.wid...@ericsson.com> wrote: > > 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
