Hi Nagu, I think it's not convenient for users if AMFD doesn't support SA_IMM_ATTR_VALUES_REPLACE in its CCB callbacks. For example, there's a node-group including 2 nodes.
root@SC-1:~# immlist -a saAmfNGNodeList safAmfNodeGroup=test,safAmfCluster=myAmfCluster saAmfNGNodeList=safAmfNode=SC-1,safAmfCluster=myAmfCluster:safAmfNode=SC-2,safAmfCluster=myAmfCluster If the user want to change the node-group to only PL-3, here's what they have to do: root@SC-1:~# immcfg -a saAmfNGNodeList-="safAmfNode=SC-2,safAmfCluster=myAmfCluster" safAmfNodeGroup=test,safAmfCluster=myAmfCluster root@SC-1:~# immcfg -a saAmfNGNodeList+="safAmfNode=PL-3,safAmfCluster=myAmfCluster" safAmfNodeGroup=test,safAmfCluster=myAmfCluster root@SC-1:~# immcfg -a saAmfNGNodeList-="safAmfNode=SC-1,safAmfCluster=myAmfCluster" safAmfNodeGroup=test,safAmfCluster=myAmfCluster If AMFD supports SA_IMM_ATTR_VALUES_REPLACE, all they have to do is: root@SC-1:~# immcfg -a saAmfNGNodeList="safAmfNode=PL-3,safAmfCluster=myAmfCluster" safAmfNodeGroup=test,safAmfCluster=myAmfCluster And they don't have to know what node that node-group currently consists of (in this case, SC-1 and SC-2). I think amf should have an enhancement ticket for that. BR, Hung Nguyen - DEK Technologies -------------------------------------------------------------------------------- From: Anders Bjornerstedt [email protected] Sent: Wednesday, December 02, 2015 4:03PM To: Nagendra Kumar [email protected] Cc: Hung Nguyen, Neelakanta Reddy, Opensaf-devel, Anders, Zoran Milinkovic [email protected], [email protected], [email protected], [email protected], [email protected] Subject: Re: RE: RE: [devel] [PATCH 1 of 1] imm: Canonicalize attributes presented by OiCcbObjectModifyCallback [#801] Hi Nags, It seems from what you describe that the AMF actually has a number of defects in relation to how it handles the IMM OI Modify callback. These defects in the AMF should of course be fixed as soon as possible and a must be fixed before the AMF could move to a higher version of the IMMA-OI API. Specifically the AMF interpreation of the SAI_MM_ATTR_INITIALIZED flag is not correct, if I have undertood your description correctly. The AMF may add restrictions, i.e. be stricter than the basic IMM spec on hat kinds of changes in value it allows on certain objects/attributes. But such restrictions must be VALUE based and must be checked in the comppleted callback. They must not be OPERATIONAL restrictions. That is the AMF can not dictate that a way of updating an attribute that is allowed by the IMM is not allowed by the AMF. The only thing that the AMF has veto rights over is the value change as such, not HOW the value change is expressed when it is expressed according to the genrically allowed ways of expressing a amdificatioin in the IMM API. I should say that I am not even 100% sure I have understood all that you have said in relation to the AMFs aparetntly particular and selective way of supporting the IMM modify operations. But that in itself tells me and you something quite impportant does it not ? The whole point of #801 is to simplify the actual usage of the modify API at least on the OI-callback side, to allign it more with classical database APIs. Currently the IMM API is more complex than it needs to be in relation to modifications. This aadds risk that there will be misunderstandiings between what the OM user expresses and what the OI implementer supports. The AMFs current OI implementation is now a fantastic example of this. The conclusion of that should be that #801 is all the more needed and that the AMF should accomadate it, not prevent it. /AndersBj > ----Ursprungligt meddelande---- > Från : [email protected] > Datum : 02-12-2015 - 06:43 (GMT) > Till : [email protected] > Kopia : [email protected], [email protected], > [email protected], [email protected], > [email protected] > Ämne : RE: RE: [devel] [PATCH 1 of 1] imm: Canonicalize attributes presented > by OiCcbObjectModifyCallback [#801] > > Hi Anders, > Thanks for your reply. > So, if this feature is implemented as A.2.18(say), it will have no impact on > Amf or any other applications(As Amf is initialized with A.2.11 as of now). > But, let us say, later on, Imm implements another feature with versions > A.2.18 or A.2.19 and Amf or any other applications need it. > Then either Amf has to go to version A.2.18 or A.2.19 and it has to go for > many changes in the code because > ticket #801 has been already implemented in A.2.18 or A.2.19. > And say Amf doesn't need this feature of #801. > So, what are the ways Amf can isolates itself from using #801 but want to use > another feature implemented > with version A.2.18 or A.2.19. > > Thanks > -Nagu > >> -----Original Message----- >> From: Anders Bjornerstedt [mailto:[email protected]] >> Sent: 01 December 2015 20:47 >> To: Nagendra Kumar >> Cc: [email protected]; [email protected]; Reddy Neelakanta >> Reddy Peddavandla; [email protected]; opensaf- >> [email protected] >> Subject: Re: RE: [devel] [PATCH 1 of 1] imm: Canonicalize attributes >> presented by OiCcbObjectModifyCallback [#801] >> >> Hi Nags, >> >> The AMF should simply not change its IMMA-OI interface version to the next >> version (A.2.17 if I am not mistaken). >> As long as it keeps the IMMA-OI version to its current version there is no >> change in behavior and there is not problem. >> >> Regarding point (1) I assume you are talking about the proposal in #801 to >> send all attribute values in the first create or modify callback for >> any particular object sent to an OI that has just attached. I am not sure >> Hung >> has implemented that feature in #801. >> In any case the basic proposal for #801 is to only send the after values for >> attributes that are actually being proposed for change in a modify operation. >> >> Regarding point (2) it sounds really strange. For single valued attributes I >> would say REPLACE is the operation that makes most sense t o use all the >> time. >> It never occured to me that any one would use add and remove on a single >> valued attribute, except for the special case to go from no value to one >> value >> or vice versa, but replace could also be used for that, so why use add and >> remove ? >> To me add and remove only really make sense on multi valued attributes. >> I know the SAF IMM spec talks about doing add and remove on single valued >> attributes in the sense of adding or removing the attribute as such >> from an instance (even though the attribute is still defined in the >> class!). This >> very strange feature has never been supported by the OpenSAF IMM >> and so we may have a discrepancy between AMF and IMM here of precisely >> the kind that I was warning about and for which enhancement #801 is >> partly intended. Example: If you do remove on a single valued attribute X in >> object A and after that try to fetch attribute X using an acccessor get on A, >> do you expect to get ERR_NOT_EXIST ? The attribute does exist according to >> the class definition ! If you do expect to get ERR_NO_EXIST then you will be >> disapointed. >> The IMM will not reply with ERR_NOT_EXIST but with the empty value (if the >> value for the attribute is currently empty). I have never understood the >> point in allowing both the empty value for an attribute AND the notion of the >> attribute not *existing* in the instance of a class where the class declares >> the attribute to exist. So the OpenSAF IMM does not support that notion of >> both a null value and a super null value. >> All this complexity in the SAF IMM data model for expressing the same kind >> of modification in seeral ways is not helping anyone. It is only causing >> confusion and dislocation in what is supported, what is comprehended by >> OM users andwhat is comprehended by OI users. >> >> Regarding point (3) I have touble folowing what you are saying (which is sad >> when I have worked with the IMM for so many years) The >> SA_IMM_ATTR_INITIALIZED flag, >> which I assume you are referring to, means only that at object creation time, >> the attribute must have a value assigned to it. That is the attribute is not >> allowed to be >> empty at object create time. The flag does not mean the value can not be >> changed/updated (!) and asuming that it *is* to be updated which it is >> allowed to be >> according to boththe IMM spec and the SAF spec, then you should >> preferrably use replace, so that the attribute has a value at all times. If >> you >> for some strange reason >> prefered to acheive the same replacement by doing the more complex >> excercise of first a remove and then an add, the attribute would be empty >> after the remove and >> before the add. >> >> Anyway to sumarize: If >>we<< i.e. us developers of OpensAF have trouble >> agreeing on the semantics of the SAF model operations, then what is to be >> expected of users ? >> So we really do need to simplify where simplification is possible and >> particularly where there is absoolutely no loss in expressive power after >> doing the simplification. >> And as I say this change is introduced in the next version. Any OI that does >> not set the version to this version will get the old behvior. >> The new version does not change behavior in any way that violates the SAF >> spec. Thus all the cases described here where the AMF will report problems is >> due to >> problems in the AMF relative to supporting the *current* SAF spec. Using >> replcae on a single valued attribue is alllowed according to the SAF spec and >> having the AMF >> being more restrictive than the IMM on what IMM operations are allowed in >> general is not a good idea. The AMF or any OI should of course be more >> retrictive than >> the IM in what it allows according to *semantic* rules. Such semantic rules >> are always to be evalueated in the completed callback, not in the operation >> callbacks. >> >> /AndersBj >> >> >>> ----Ursprungligt meddelande---- >>> Från : [email protected] >>> Datum : 01-12-2015 - 10:26 (GMT) >>> Till : [email protected], [email protected] >>> Kopia : [email protected], >> [email protected], [email protected], >> [email protected] >>> Ämne : RE: [devel] [PATCH 1 of 1] imm: Canonicalize attributes presented >> by OiCcbObjectModifyCallback [#801] >>> Hi Anders, >>> Below is Amf problems with this enhancements: >>> 1. The code doesn't allow to modify some attributes, because those >> attributes/features are not supported yet. So, Amf will reject the modify >> callback with this feature. >>> 2. REPLACE is used only for multi-valued attributes. For others, we are >> modifying the attributes as replacement. But there is no check whether the >> attributes has been modified with the same value. Hence there may be >> chances that the many triggers of change will occur at the same time(not >> desired). >>> 3. Amf is rejecting REPLACE option for Initialized attributes(e.g. >> saAmfNGNodeList) as of now. So, modify callback will get rejected. >>> The similar issues exists in Log service, and others. >>> >>> So, it gives me impression that the this feature has application backward >> compatibility issues and need to modify Middleware and other User's >> applications. >>> Thanks >>> -Nagu >>>> -----Original Message----- >>>> From: Anders Bjornerstedt [mailto:[email protected]] >>>> Sent: 30 November 2015 23:26 >>>> To: Reddy Neelakanta Reddy Peddavandla >>>> Cc: [email protected]; >> [email protected]; >>>> Nagendra Kumar; [email protected]; [email protected] >>>> Subject: Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes presented >> by >>>> OiCcbObjectModifyCallback [#801] >>>> >>>> If I where to play the "devils advocate" and try hard to find some positive >>>> argument for still supporting add and remove for ccb-modify in OI >> callbacks, >>>> I guess it could be "performance". If we have a multivalued attribute X >> that >>>> is "large" and want to add one element to the set/bag then of course >>>> deleting >>>> the whole set/bag X and recreating X+ (1element) could be argued to be >>>> inefficient in execution. >>>> >>>> But then taking the stance of the devils devils advocate, which cancels the >>>> devils, I would argue that such a performance argument should be >> ignored >>>> because config data is not "big data" and config data is not updated >>>> frequently. I would also say that having OIs support not just replace, but >> also >>>> add >>>> and remove is an invitation for OI implementers to add redundant >> software >>>> with the added risk of bugs that can make the OI representation of the >> data >>>> deviate from the imm rep, without this always being trivially or quickly >>>> detected. >>>> >>>> /AndersBj >>>> >>>> >>>>> ----Ursprungligt meddelande---- >>>>> Från : [email protected] >>>>> Datum : 30-11-2015 - 06:57 (GMT) >>>>> Till : [email protected] >>>>> Kopia : [email protected], [email protected], >>>> [email protected], [email protected], >>>> [email protected] >>>>> Ämne : Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes >> presented >>>> by OiCcbObjectModifyCallback [#801] >>>>> Hi , >>>>> >>>>> Adding Nags, to know more on AMF dealing the modify callback and any >>>>> impacts because of this enhancement for AMF. >>>>> >>>>> Thanks, >>>>> Neel. >>>>> >>>>> On Friday 27 November 2015 10:01 PM, Anders Bjornerstedt wrote: >>>>>> Hi Neel, >>>>>> >>>>>> We dont need a new callback because the change is backwards >>>> compatible. >>>>>> Yes OIs such as the AMF has code for dealing with delete and >>>> addoperations for modify callbacks, but the AMF *must* also have code >>>>>> for dealing with replace. >>>>>> >>>>>> The AMF-OI code for dealing with delete and add will just be obsolete >>>> code when the 5.0 version of the API is used. >>>>>> That should not be a problem. >>>>>> I dont see any need for adding a new API if it has the same signature >> as >>>> the old. >>>>>> If there is a point it would *only* be to avoid having new OI >> implementers >>>> adding useless code for handling delete and add operations. >>>>>> But I think that simplification for new OIs could be communicated just >> via >>>> documentation. >>>>>> /AndersBj >>>>>> >>>>>> >>>>>>> ----Ursprungligt meddelande---- >>>>>>> Från : [email protected] >>>>>>> Datum : 27-11-2015 - 13:36 (GMT) >>>>>>> Till : [email protected] >>>>>>> Kopia : [email protected], >>>> [email protected], [email protected], >>>> [email protected] >>>>>>> Ämne : Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes >>>> presented by OiCcbObjectModifyCallback [#801] >>>>>>> Hi AndersBj, >>>>>>> >>>>>>> If canonicalizing the modify callback is done, then there are >> middleware >>>>>>> services like amf, plm >>>>>>> which uses SA_IMM_ATTR_VALUES_DELETE and >>>> SA_IMM_ATTR_VALUES_ADD for >>>>>>> comparison and do operations based on this. >>>>>>> >>>>>>> Instead of providing the canocicalizing attribute values in older >>>>>>> callbacks, add a new callback for modify. like >>>>>>> SaImmOiCcbObjectModifyCallbackT_3 a new callback for modify, for >> all >>>>>>> attributes with OI latest(5.0) version. >>>>>>> >>>>>>> Thanks, >>>>>>> Neel. >>>>>>> >>>>>>> On Thursday 26 November 2015 08:34 PM, Anders Bjornerstedt >> wrote: >>>>>>>> Hi Neel, >>>>>>>> >>>>>>>> Eliminating add/delete and instead simply using replace is the >>>> canocicalizing (or normal forming) the modify callback. >>>>>>>> This is the whole point of #801. >>>>>>>> >>>>>>>> I dont follow you in what sense the "wrong" operation is sent to the >> OI. >>>>>>>> The point is that any add or delete operation can be transformed to >> a >>>> replace with the after value that would have been the result of an add or >>>> delete. >>>>>>>> So the replace with the after value is equivalent in outcome. >>>>>>>> >>>>>>>> /AndersBj >>>>>>>> >>>>>>>> >>>>>>>>> ----Ursprungligt meddelande---- >>>>>>>>> Från : [email protected] >>>>>>>>> Datum : 26-11-2015 - 13:29 (GMT) >>>>>>>>> Till : [email protected] >>>>>>>>> Kopia : [email protected], [email protected], >>>> [email protected], [email protected] >>>>>>>>> Ämne : Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes >>>> presented by OiCcbObjectModifyCallback [#801] >>>>>>>>> Hi AndersBj, >>>>>>>>> >>>>>>>>> Comments below. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Neel. >>>>>>>>> >>>>>>>>> On Thursday 26 November 2015 05:03 PM, Anders Bjornerstedt >> wrote: >>>>>>>>>> One more thing about appliers and #801. >>>>>>>>>> >>>>>>>>>> The protocol for the *special applier* function must not be >> altered >>>> by #801. >>>>>>>>> Yes, the special applier protocol should not be altered. >>>>>>>>> But, I have a concern the way the patch is published(which is taken >>>> from >>>>>>>>> special appliers): >>>>>>>>> If all the attributes need to be delivered in the callback, why >>>>>>>>> ADD/DELETE is changed to REPLACE operation. >>>>>>>>> The behavior of changing ADD/DELETE to REPLACE operation will >>>> send wrong >>>>>>>>> modify operations to OI/applier. >>>>>>>>>> /AndersBj >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> ----Ursprungligt meddelande---- >>>>>>>>>>> Från : [email protected] >>>>>>>>>>> Datum : 26-11-2015 - 09:52 (WET) >>>>>>>>>>> Till : [email protected] >>>>>>>>>>> Kopia : [email protected], >>>> [email protected], [email protected], >>>> [email protected] >>>>>>>>>>> Ämne : Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes >>>> presented by OiCcbObjectModifyCallback [#801] >>>>>>>>>>> Hi Neel, >>>>>>>>>>> >>>>>>>>>>> Ok so we are discussing only the regular OI case. >>>>>>>>>>> >>>>>>>>>>> Concerning point (1) regular OIs and adding or not adding >>>> unchanged attribute values, I suggest that this could be made an option. >>>>>>>>>>> Perhaps setting the OI library version to this latest (5.0 ?) >>>>>>>>>>> version >>>> could be used as the discriminator. >>>>>>>>> what are the thoughts on SaImmOiCcbObjectModifyCallbackT_3 a >>>> new >>>>>>>>> callback for modify, for all attributes . >>>>>>>>>>> The advantage with this aproach is that it releives also regular >> OIs >>>> from the "initialization problem", i.e. the problem that a newly started >>>>>>>>>>> OI process faces: How to get the initial state of its config data? >> The >>>> SAF spec provides no explicit solution for this problem, most liklely >>>>>>>>>>> because they did not think about it and certainly because SAF did >>>> not have any reference implementation for the spec before freezing the >>>> spec. >>>>>>>>>>> The solution the OpenSAF IMM documentation proposes is for >> the >>>> OI to set admin-owner to some hopefully exclusive value while reading >> the >>>>>>>>>>> data using unsafe read (search and accessor get). This is not >> really a >>>> satisfactory solution since it is not 100% guaranteed to provide isolation. >>>>>>>>>>> It works in practice (most of the time) because config data is in >>>> general updated with low frequency and most OM users *hopefully*, set >> the >>>> CCB >>>>>>>>>>> flags to correctly to require OI presence. But "hope" and "rarely" >>>> are not terms that should be asssociated with avoiding inconsistent >> coonfig >>>> data. >>>>>>>>>>> Concerning (b) waste of resource, I agree that this is the case, >>>> particularly if the config data is bulky. So one solution here could be to >> only >>>>>>>>>>> add all the unchanged attribute values in the *first* callback >> made >>>> to an OI that has just attached. This is an impprovement sugggestion to >>>> [#801]. >>>>>>>>>>> It could just as welll be used also for appliers. >>>>>>>>> The book keeping of objects to a particular OI/applier, will become >> an >>>>>>>>> additional responsibility in IMM database. >>>>>>>>>>> Converning point (c): I would say that how light or heavy an >> appplier >>>> vs OI is is completely up to the developers of these functions. >>>>>>>>>>> They should preferrably get the same callbacks with the same >>>> contents as the OI unless there is a very good reason to break that rule. >>>>>>>>>>> The reason is the old KISS rule. Not folowing it will result in the >>>> average OI/applier developer getting it wrong. As we all know the >> average >>>>>>>>>>> developer does not read much if any documentation, unless they >>>> really run into problems... >>>>>>>>>>> Concerning appliers in the form supported by OpenSAF not being >>>> SAF standard, that is correct. >>>>>>>>>>> But that of course does not mean there are no strict rules. The >>>> applier concept must strictly obey the specification that is documented by >>>> OpenSAF. >>>>>>>>>>> So I of course interpret what you are saying as not that there are >> no >>>> strict rules for appliers, but that OpenSAF is free to set the rules. >>>>>>>>>>> OpenSAF has set the current strict rules for appliers. >>>>>>>>> I agree, that the appliers and OI callbacks must have same >>>> information. >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> /AndersBj >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> ----Ursprungligt meddelande---- >>>>>>>>>>>> Från : [email protected] >>>>>>>>>>>> Datum : 26-11-2015 - 07:07 (GMT >>>>>>>>>>>> Till : [email protected] >>>>>>>>>>>> Kopia : [email protected], [email protected], >>>> [email protected], [email protected] >>>>>>>>>>>> Ämne : Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes >>>> presented by OiCcbObjectModifyCallback [#801] >>>>>>>>>>>> Hi AndersBj, >>>>>>>>>>>> >>>>>>>>>>>> 1)For the OI, only the attribute values that have actually being >>>> changed >>>>>>>>>>>> must be included in the modify callback. >>>>>>>>>>>> Even though the change is backward compatible, The following >>>> can be the >>>>>>>>>>>> reasons for not sending unchanged values : >>>>>>>>>>>> a. It follows SAF spec >>>>>>>>>>>> b. waste of resources. >>>>>>>>>>>> c. OI are not light as appliers, can maintain the information on >>>>>>>>>>>> modification objects OI are expecting. >>>>>>>>>>>> >>>>>>>>>>>> 2) For the appliers, the change may be allowed: >>>>>>>>>>>> a. most of the appliers are light-weight and may not have >> previous >>>>>>>>>>>> information on the object attributes >>>>>>>>>>>> b. Appliers are not SAF standard (no strict rules) >>>>>>>>>>>> c. changing of modify type from ADD/DELETE to REPLACE may >> not >>>> have any >>>>>>>>>>>> effects on appliers, as they are just information receivers. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Neel. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thursday 26 November 2015 02:22 AM, Anders Bjornerstedt >>>> wrote: >>>>>>>>>>>>> Hi Neel, >>>>>>>>>>>>> >>>>>>>>>>>>> Writing from the sidelines :-) >>>>>>>>>>>>> >>>>>>>>>>>>> I dont see any backwards compatibility issue as long as the OI >>>> callback contains information that is equivalent in outcome/result to the >>>> effect of the execution of the OM input. >>>>>>>>>>>>> As long as the callback contains what *could* have been the >> OM >>>> input and the resulting value change is exactly the same, it should be ok. >>>>>>>>>>>>> Remembe ralso that the OM users and the OI/application are >>>> decoupled. >>>>>>>>>>>>> Only the attribute values that have actually been changed >> must >>>> be included in the OI callback. >>>>>>>>>>>>> Including unchanged values is not strictly necessary and could >> be >>>> argued is a waste of resources. >>>>>>>>>>>>> Still that would not be a backwards compatibility issue. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> AndersBj >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> ----Ursprungligt meddelande---- >>>>>>>>>>>>>> Från : [email protected] >>>>>>>>>>>>>> Datum : 25-11-2015 - 11:25 (GMT) >>>>>>>>>>>>>> Till : [email protected], >>>> [email protected], [email protected] >>>>>>>>>>>>>> Kopia : [email protected] >>>>>>>>>>>>>> Ämne : Re: [devel] [PATCH 1 of 1] imm: Canonicalize >> attributes >>>> presented by OiCcbObjectModifyCallback [#801] >>>>>>>>>>>>>> Hi Hung, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The following is required by this ticket: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1. The saImmOiCcbObjectModifyCallback for implementer >> must >>>> pass only >>>>>>>>>>>>>> the values of the attributes actually >>>>>>>>>>>>>> modified by this modify operation will be provided. That is no >>>> deviation >>>>>>>>>>>>> >from current implementation for OI. >>>>>>>>>>>>>> The present patch changes ADD/DELETE to REPLACE for OI >> also. >>>>>>>>>>>>>> 2. The enhancement is about to pass "all writable after- >> image >>>>>>>>>>>>>> attributes" to the saImmOiCcbObjectModifyCallback for >>>> appliers. >>>>>>>>>>>>>> while passing change modify type ADD/DELETE to REPLACE. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The present patch passes only the modification attributes >> that >>>> are >>>>>>>>>>>>>> modified by the modify Ccb operation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have to NACK the patch. >>>>>>>>>>>>>> >>>>>>>>>>>>>> /Neel. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Friday 09 October 2015 04:45 PM, Hung Nguyen wrote: >>>>>>>>>>>>>>> osaf/services/saf/immsv/immnd/ImmModel.cc | 27 >>>> +++++++++++++++++++++++++++ >>>>>>>>>>>>>>> 1 files changed, 27 insertions(+), 0 deletions(-) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This patch modifies the content of incoming >>>> IMMND_EVT_A2ND_OBJ_MODIFY messages. >>>>>>>>>>>>>>> If the modType is SA_IMM_ATTR_VALUES_ADD or >>>> SA_IMM_ATTR_VALUES_DELETE, >>>>>>>>>>>>>>> it will be converted to SA_IMM_ATTR_VALUES_REPLACE >> and >>>> the values of the attr-mod will be the values in the after image. >>>>>>>>>>>>>>> diff --git a/osaf/services/saf/immsv/immnd/ImmModel.cc >>>> b/osaf/services/saf/immsv/immnd/ImmModel.cc >>>>>>>>>>>>>>> --- a/osaf/services/saf/immsv/immnd/ImmModel.cc >>>>>>>>>>>>>>> +++ b/osaf/services/saf/immsv/immnd/ImmModel.cc >>>>>>>>>>>>>>> @@ -8705,6 +8705,33 @@ >>>> ImmModel::ccbObjectModify(const ImmsvOmC >>>>>>>>>>>>>>> if(err != SA_AIS_OK) { >>>>>>>>>>>>>>> break; //out of for-loop >>>>>>>>>>>>>>> } >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> + if (p->attrModType != >> SA_IMM_ATTR_VALUES_REPLACE) >>>> { >>>>>>>>>>>>>>> + osafassert(p->attrValue.attrValuesNumber); >>>>>>>>>>>>>>> + /* Free attribute values of the attr-mod */ >>>>>>>>>>>>>>> + immsv_evt_free_att_val_raw(&(p- >>>>> attrValue.attrValue), >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> p->attrValue.attrValueType); >>>>>>>>>>>>>>> + if (p->attrValue.attrValuesNumber > 1) { >>>>>>>>>>>>>>> + immsv_free_attr_list_raw(p- >>>>> attrValue.attrMoreValues, >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> p->attrValue.attrValueType); >>>>>>>>>>>>>>> + p->attrValue.attrMoreValues = NULL; >>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>> + p->attrValue.attrValuesNumber = 0; >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> + TRACE("Canonicalizing attr-mod for attribute '%s'", >>>> attrName.c_str()); >>>>>>>>>>>>>>> + p->attrModType = >> SA_IMM_ATTR_VALUES_REPLACE; >>>>>>>>>>>>>>> + if (!attrValue->empty()) { >>>>>>>>>>>>>>> + attrValue->copyValueToEdu(&(p- >>>>> attrValue.attrValue), >>>>>>>>>>>>>>> + (SaImmValueTypeT) p- >>>>> attrValue.attrValueType); >>>>>>>>>>>>>>> + if (attrValue->extraValues()) { >>>>>>>>>>>>>>> + osafassert(attrValue->isMultiValued()); >>>>>>>>>>>>>>> + ImmAttrMultiValue* multiVal = >>>> (ImmAttrMultiValue *) attrValue; >>>>>>>>>>>>>>> + multiVal->copyExtraValuesToEdu(&(p- >>>>> attrValue.attrMoreValues), >>>>>>>>>>>>>>> + >>>>>>>>>>>>>>> (SaImmValueTypeT) p- >>>>> attrValue.attrValueType); >>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>> + p->attrValue.attrValuesNumber = 1 + attrValue- >>>>> extraValues(); >>>>>>>>>>>>>>> + } /* else, attrValuesNumber is already set to 0 */ >>>>>>>>>>>>>>> + } >>>>>>>>>>>>>>> }//for (p = ....) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> // Prepare for call on PersistentBackEnd >>>>>>>>>>>>>> -------------------------------------------------------------------------- >> ---- >>>>>>>>>>>>>> Go from Idea to Many App Stores Faster with Intel(R) XDK >>>>>>>>>>>>>> Give your users amazing mobile app experiences with Intel(R) >>>> XDK. >>>>>>>>>>>>>> Use one codebase in this all-in-one HTML5 development >>>> environment. >>>>>>>>>>>>>> Design, debug & build mobile apps & 2D/3D high-impact >> games >>>> for multiple OSs. >>>> http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> Opensaf-devel mailing list >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >>>>>>>>>>>>>> ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ Opensaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-devel
