Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes presented by OiCcbObjectModifyCallback [#801]

[Neelakanta R. <red...@or...>]

Hi Hung,

I agree that the enhancement will simplify the tasks for OI.
The worry , expressed was about the migration of OI (at least 
middle-ware) to newer version and impacts.

The patch published previously, was not according to the discussion.
I would like to add some points before you start working :

1. The previously published patch the modify callback is not receiving 
all attributes values(i.e only the modified values by OM are received).
2.  As, you said version changes must be added.
3. Some, discussions here, if the attribute is not writable then we 
should not send the attribute to modify callback(may be this can be done 
at later point of time in another defect after this enhancement).

Thanks,
Neel.

On Friday 04 December 2015 03:11 PM, Hung Nguyen wrote:
> Hi Neel,
>
> If you agree on this, I will send new patch with version restriction 
> for review.
> The current patch doesn't check versions that OIs/appliers register.
>
>
> Thanks and Best Regards,
>
> Hung Nguyen - DEK Technologies
>
>
> -------------------------------------------------------------------------------- 
>
> From: Anders Bjornerstedt and...@co...
> Sent: Friday, December 04, 2015 12:30AM
> To: Nagendra Kumar
>     nag...@or...
> Cc: Neelakanta Reddy, Opensaf-devel, Hung Nguyen, Anders, Zoran 
> Milinkovic
>     red...@or..., ope...@li..., 
> hun...@de..., an...@ac..., 
> zor...@er...
> Subject: Re: RE: [devel] [PATCH 1 of 1] imm: Canonicalize attributes 
> presented by OiCcbObjectModifyCallback [#801]
>
>
> Hi Nags,
>
> Regarding point (1) The problem is not that the AMF is not supporting 
> "a few" of the attribute modification variants.
> The problem is that the AMF is not supporting the most basic 
> modification type there is.
> This is a bug/omissin on the part of the AMF and must be fixed soooner 
> or later in the AMF.
> So we will now ignore your point (1).
>
> Regarding point (2) there seems to be a missunderstanding.
> No one is suggesting sending the values of all attributes all the time.
> The suggestion was only to send all attributes the first time for any 
> particular object after OI attach.
> But that suggestion may be quite complicated to implement since the 
> server side needs to keep track of which objects have been pushed once 
> to the OI.
> So we wrill drop that feature. The down side is then that the OI still 
> has the initialization problem which currently has no safe solution.
>
> So the grand conclusion is that we will go ahead with #801 using the 
> current API.
> That change is that the OI will only receive modifications of type 
> REPLACE.
> This is the simplest and most fundamental form of modification and all 
> OIs must suppport it.
> This is a backeards compatible change.
> But the change will only be done for OIs that register with A.2.18 (or 
> the release where enhancement #801 is fixed).
> I remind again that the AMF also seems to have an incorrect 
> implementation for SA_IMM_ATTR_INITIALIZED.
> You have not acknowledged this. No one has complained about it 
> apparently. The only reason the initialized flag came up
> in this discussion was that you referred to it as also being some kind 
> of problem related to #801.
> But *if* the initialized flag in the AMF has any issues related to 
> #801  then it would be a bug in the AMF.
>
> To the extent that the AMF-OI does not support the replace 
> modification type on some attribures, the AMF will be unable
> to upgradde to a newer IMM API before fixing that.  This seems like a 
> fair trade off not just for the AMF but for any OIs
> out there that for some strange reason do not support replace.
>
> This concludes the analysis tof this issue as far as I am concerend.
> Hung you can go ahead and deliver according to these premises.
> If anyone still objects to this then I would say take it up with the 
> OpenSAF TC.
>
> Thanks
> AndersBj
>
>
>> ----Ursprungligt meddelande----
>> Från : nag...@or...
>> Datum : 03-12-2015 - 11:19 (GMT)
>> Till : and...@co..., hun...@de...
>> Kopia : zor...@er..., an...@ac..., 
>> ope...@li..., red...@or...
>> Ämne : RE: [devel] [PATCH 1 of 1] imm: Canonicalize attributes 
>> presented by OiCcbObjectModifyCallback [#801]
>>
>> Hi Anders/Hung,
>>
>> 1.    Since Amf is not supporting few of the attribute modification 
>> in one class, then the callback will be rejected.
>> 2.    Honouring Callback with all the attributes has performance 
>> issues in all the user's applications.
>>
>> So, my suggestion is that you should support Older SAF Specifications 
>> and New feature together. That means if Older applications and New 
>> feature's application should work together.
>> So, I think Neel suggestion of having a different callback for this 
>> feature sounds good to me. It helps applications registering for 
>> Older and New type of callback of their choice(Why to kill user's 
>> choice :) ).
>>
>> Thanks
>> -Nagu
>>
>>> -----Original Message-----
>>> From: Anders Bjornerstedt [mailto:and...@co...]
>>> Sent: 03 December 2015 14:59
>>> To: hun...@de...
>>> Cc: zor...@er...; an...@ac...; Nagendra Kumar;
>>> ope...@li...; Reddy Neelakanta Reddy Peddavandla
>>> Subject: Re: [devel] [PATCH 1 of 1] imm: Canonicalize attributes 
>>> presented by
>>> OiCcbObjectModifyCallback [#801]
>>>
>>> Agree with Hung, except I claim this has to be a defect on AMF.
>>> The reason being that we need to get a principle clear: OIs must at 
>>> least
>>> support the "vanilla" case (or simplest way) of updating an 
>>> attribute in a
>>> modify operation.
>>>
>>> An OI implementation curently must in principle support all allowed 
>>> ways of
>>> updating an attribute as defined by the IMM spec.
>>> After the enhancement of #801 is fixed in the IMM, OIs may simplify 
>>> and only
>>> support the simplest, i.e. replacement way of updating an attribute, 
>>> if that OI
>>> sets the version to A.2.18 (or whatever release #801 is fixed in).
>>>
>>> An OI should really only be concerned with the end replacement value 
>>> of a
>>> change and not how it is expressed operationally.
>>>
>>> Another reason the AMF fix has to be declared a defect is that if it 
>>> is declared
>>> an enhancement then #801 can not be fixed until after the AMF fix is 
>>> done.
>>> It would force the IMM maintainers to be aware of and be backwards
>>> compatible with any and all selective OI implementations.
>>> This is clearly impossible and violates the basic principle of 
>>> decoupling over
>>> interfaces.
>>>
>>> I also remind of the separate issue that there seems also to be an 
>>> incorrect
>>> interpretation of the INITIALIZED flag in thecurrent AMF 
>>> implementation.
>>> An OI is not free to have its own more restrictive interpretation of 
>>> a flag
>>> defined in the IMM spec.
>>>
>>> An OI *is* free to have a more restrictive interpretation/rules 
>>> governing its
>>> data-moodel than the constraints or degrees of freedom allowed by the
>>> IMM but such restrictions must be value based. Thus an if an integer 
>>> attribute
>>> actually is an enum, then the OI may reject an update if the value 
>>> is not in
>>> range.
>>> Rules governing the combined value in severall atributes or even 
>>> several
>>> objects can only be validated in the completed callback.
>>>
>>>
>>> /AndersBj
>>>
>>>> ----Ursprungligt meddelande----
>>>> Från : hun...@de...
>>>> Datum : 03-12-2015 - 04:59 (GMT)
>>>> Till : nag...@or...
>>>> Kopia : and...@co..., red...@or...,
>>>> ope...@li..., an...@ac...,
>>>> zor...@er... Ämne : Re: [devel] [PATCH 1 of 1] imm:
>>>> Canonicalize attributes presented by OiCcbObjectModifyCallback [#801]
>>>>
>>>> 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=S
>>>> C-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 and...@co...
>>>> Sent: Wednesday, December 02, 2015 4:03PM
>>>> To: Nagendra Kumar
>>>>      nag...@or...
>>>> Cc: Hung Nguyen, Neelakanta Reddy, Opensaf-devel, Anders, Zoran
>>> Milinkovic
>>>>      hun...@de..., red...@or...,
>>>> ope...@li..., an...@ac...,
>>>> zor...@er...
>>>> 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 : nag...@or...
>>>>> Datum : 02-12-2015 - 06:43 (GMT)
>>>>> Till : and...@co...
>>>>> Kopia : zor...@er..., an...@ac...,
>>>>> red...@or..., hun...@de...,
>>>>> ope...@li...
>>>>> Ä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:and...@co...]
>>>>>> Sent: 01 December 2015 20:47
>>>>>> To: Nagendra Kumar
>>>>>> Cc: zor...@er...; an...@ac...; Reddy
>>> Neelakanta
>>>>>> Reddy Peddavandla; hun...@de...; opensaf-
>>>>>> de...@li...
>>>>>> 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 : nag...@or...
>>>>>>> Datum : 01-12-2015 - 10:26 (GMT)
>>>>>>> Till : and...@co..., red...@or...
>>>>>>> Kopia : ope...@li...,
>>>>>> hun...@de..., an...@ac...,
>>>>>> zor...@er...
>>>>>>> Ä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:and...@co...]
>>>>>>>> Sent: 30 November 2015 23:26
>>>>>>>> To: Reddy Neelakanta Reddy Peddavandla
>>>>>>>> Cc: ope...@li...;
>>>>>> hun...@de...;
>>>>>>>> Nagendra Kumar; an...@ac...; zor...@er...
>>>>>>>> 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 : red...@or... Datum : 30-11-2015 - 06:57
>>>>>>>>> (GMT) Till : and...@co... Kopia :
>>>>>>>>> zor...@er..., an...@ac...,
>>>>>>>> hun...@de..., opensaf-
>>> de...@li...,
>>>>>>>> nag...@or...
>>>>>>>>> Ä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 :
>>>>>>>>>>> red...@or... Datum : 27-11-2015 - 13:36 (GMT)
>>>>>>>>>>> Till : and...@co... Kopia :
>>>>>>>>>>> ope...@li...,
>>>>>>>> hun...@de..., an...@ac...,
>>>>>>>> zor...@er...
>>>>>>>>>>> Ä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 :
>>>>>>>>>>>>> red...@or... Datum : 26-11-2015 - 13:29
>>> (GMT)
>>>>>>>>>>>>> Till : and...@co... Kopia :
>>>>>>>>>>>>> zor...@er..., an...@ac...,
>>>>>>>> hun...@de..., opensaf-
>>> de...@li...
>>>>>>>>>>>>> Ä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 :
>>>>>>>>>>>>>>> and...@co... Datum : 26-11-2015 - 09:52
>>>>>>>>>>>>>>> (WET) Till : red...@or... Kopia :
>>>>>>>>>>>>>>> ope...@li...,
>>>>>>>> hun...@de..., an...@ac...,
>>>>>>>> zor...@er...
>>>>>>>>>>>>>>> Ä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 :
>>>>>>>>>>>>>>>> red...@or... Datum : 26-11-2015 - 07:07
>>>>>>>>>>>>>>>> (GMT Till : and...@co... Kopia :
>>>>>>>>>>>>>>>> zor...@er..., an...@ac...,
>>>>>>>> hun...@de..., opensaf-
>>> de...@li...
>>>>>>>>>>>>>>>> Ä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 :
>>>>>>>>>>>>>>>>>> red...@or... Datum : 25-11-2015 -
>>> 11:25
>>>>>>>>>>>>>>>>>> (GMT) Till : hun...@de...,
>>>>>>>> and...@er..., zor...@er...
>>>>>>>>>>>>>>>>>> Kopia : ope...@li...
>>>>>>>>>>>>>>>>>> Ä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
>>>>>>>>>>>>>>>>>> Ope...@li...
>>>>>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensaf-dev
>>>>>>>>>>>>>>>>>> el
>>>>>>>>>>>>>>>>>>
>
>