Re: [devel] [PATCH 1 of 1] amfnd: Delete comp_curr_info if comp fails into TERMINATION_FAILED [#1500]

2015-12-17 Thread praveen malviya
Ack. Thanks, Praveen On 15-Dec-15 9:55 AM, Minh Hon Chau wrote: > osaf/services/saf/amf/amfnd/clc.cc | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > Escalation is configured in the way that just one component restart can lead > to su failover. If the clc cleanup script return

[devel] [PATCH 2 of 2] amfd: use simple encode/decode for si_trans [#1544]

2015-12-17 Thread Gary Lee
osaf/services/saf/amf/amfd/ckpt_dec.cc| 68 ++ osaf/services/saf/amf/amfd/ckpt_edu.cc| 53 -- osaf/services/saf/amf/amfd/ckpt_enc.cc| 63 ++--- osaf/services/saf/amf/amfd/include/ckpt.h | 3 +

[devel] [PATCH 1 of 2] amfd: use simple encode/decode for siass [#1544]

2015-12-17 Thread Gary Lee
osaf/services/saf/amf/amfd/ckpt_dec.cc| 68 +++- osaf/services/saf/amf/amfd/ckpt_edu.cc| 59 -- osaf/services/saf/amf/amfd/ckpt_enc.cc| 77 +++--- osaf/services/saf/amf/amfd/include/ckpt.h | 3 + o

[devel] [PATCH 0 of 2] Review Request for amfd: use simple encode/decode V2 [#1544]

2015-12-17 Thread Gary Lee
Summary: amfd: use simple encode/decode V2 [#1544] Review request for Trac Ticket(s): 1544 Peer Reviewer(s): AMF devs Pull request to: Hans/Praveen Affected branch(es): default Development branch: default Impacted area Impact y/n ---

Re: [devel] [tickets] [opensaf:tickets] #1605 smfd: campaign not correctly terminated after failed SI-SWAP

2015-12-17 Thread Mathivanan Naickan Palanivelu
Just as a note, I tried Option (b) and it seems to work. (Also, SMF doesn’t performs a classimplementerset() on this, but the implementerName is still available for reading because it’s a PRTO) The question would  then be -this change should be adopted in older releases too!?   Thanks, Math

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

2015-12-17 Thread Neelakanta Reddy
Hi AndersBj, 1. In the previous discussion, the following is the differentiation between OI and applier: snippet from previous discussion: 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 preferrab

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

2015-12-17 Thread Hung Nguyen
Hi Neel, I misunderstood the discussion, I will fix that. In future, do you think we will implement that sending-all-writable-attributes feature? If so, I will keep the code for canonicalizing all writable attributes. We just simply don't use it for now. Otherwise, I will clean up the unused co

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

2015-12-17 Thread Neelakanta Reddy
Hi Hung, The following is the final conclusion from the discussion and from AndersBj( view point): 1. Both Appliers and implementer "*must*" receive the same modification values for modify callback. 2. The "final" proposal below was to drop the notion of sending all values. 3. The only ch