Re: [devel] [PATCH 0 of 1] Review Request for log: improve test cases for log service [#1913]

2016-08-11 Thread A V Mahesh
Hi Canh Van Truong,


On 8/11/2016 11:50 AM, Canh Van Truong wrote:
> 2) Remove abort (safassert) in test case and handle it as test case failed.

Still seeing abort (safassert)



Suite 2: Log Service Operations
 1  PASSED   saLogStreamOpen_2() system stream OK;
 2  PASSED   saLogStreamOpen_2() notification stream OK;
 3  PASSED   saLogStreamOpen_2() alarm stream OK;
 4  PASSED   Create app stream OK;
 5  PASSED   Create and open app stream;
 
47  PASSED   saLogStreamOpen_2 with invalid filename;
48  PASSED   saLogStreamOpen_2 with maxLogRecordSize > MAX_RECSIZE, ERR;
49  PASSED   saLogStreamOpen_2 with maxLogRecordSize < 150, ERR;
50  PASSED   saLogStreamOpen_2 with stream number out of the 
limitation, ERR;
51  PASSED   logInitialize then logFinalize multiple times. keep MDS 
connection, OK;
error: in tet_saLogStreamOpen_2.c at 919: SA_AIS_ERR_ACCESS (11), 
expected OUT_OF_RANGE - exiting



-AVM

On 8/11/2016 11:50 AM, Canh Van Truong wrote:
> Summary: log: improve test cases for log service [#1913]
> Review request for Trac Ticket(s): #1913
> Peer Reviewer(s): Vu, Mahesh, Lennart
> Pull request to: Vu
> Affected branch(es): default
> Development branch: default
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>   <>
>
> changeset 66ce76934620ec6230cfc90da3082167d72392b6
> Author:   Canh Van Truong 
> Date: Fri, 05 Aug 2016 15:21:55 +0700
>
>   log: improve test cases for log service [#1913]
>
>   The patch fixes to improve following cases:
>
>   1) The APIs may return TRY_AGAIN, this may not be a fault. Writing some
>   wrapper functions here to handle TRY_AGAIN case for log API.
>
>   2) Remove abort (safassert) in test case and handle it as test case 
> failed.
>
>   3) Some test cases (in testsuite 4) have dependence on other test cases.
>   Make them independency.
>
>   4) Some test cases (in testsuite 4, 5, 6) change setting such as IMM
>   attributes values and don't restore them back to previous. Get the
>   attributes values before changing attributes, then restore its to 
> previous
>   values at end of test cases.
>
>   5) Some test cases in testsuite 6 change attributes base on the present
>   value of logMaxLogrecsize without read the present value of its. They 
> use
>   constanst values (=1024). Changing to read logMaxLogrecsize value and 
> use
>   it.
>
>
> Complete diffstat:
> --
>   tests/logsv/logtest.c |89 +++-
>   tests/logsv/logtest.h |89 +++-
>   tests/logsv/tet_LogOiOps.c|  2163 
> 
>   tests/logsv/tet_Log_recov.c   |95 +--
>   tests/logsv/tet_log_longDN.c  | 1 -
>   tests/logsv/tet_saLogDispatch.c   | 9 +-
>   tests/logsv/tet_saLogFinalize.c   |11 +-
>   tests/logsv/tet_saLogInitialize.c |26 +-
>   tests/logsv/tet_saLogLimitGet.c   |19 +-
>   tests/logsv/tet_saLogSelectionObjectGet.c |13 +-
>   tests/logsv/tet_saLogStreamClose.c|24 +-
>   tests/logsv/tet_saLogStreamOpenAsync_2.c  |15 +-
>   tests/logsv/tet_saLogStreamOpen_2.c   |   546 +---
>   tests/logsv/tet_saLogWriteLog.c   |23 +-
>   tests/logsv/tet_saLogWriteLogAsync.c  |   461 -
>   tests/logsv/tet_saLogWriteLogCallbackT.c  |   110 +++-
>   16 files changed, 2266 insertions(+), 1428 deletions(-)
>
>
> Testing Commands:
> -
> Run all test cases.
>
>
> Testing, Expected Results:
> --
> All test case passed.
>
>
> Conditions of Submission:
> -
> Ack from reviewers
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is gene

Re: [devel] [PATCH 1 of 1] cpsv: To update checkpoint user number for each node [#1669] V4

2016-08-11 Thread Vo Minh Hoang
Dear Mahesh,

Thank you very much for your help.
I send the attached patch that fix missing in encode/decode function.

Thank you and best regards,
Hoang

-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com] 
Sent: Friday, August 12, 2016 10:15 AM
To: Vo Minh Hoang 
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] cpsv: To update checkpoint user number for each
node [#1669] V4

I will test for you send the patch.

-AVM


On 8/11/2016 3:38 PM, Vo Minh Hoang wrote:
> Dear Mahesh,
>
> Would you please tell me the case that produce this error?
> I review source code and found that encode/decode function missed 1 
> attribute.
> But running test in our environment could not reproduce this problem.
>
> Thank you and best regards,
> Hoang
>
> -Original Message-
> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
> Sent: Tuesday, August 9, 2016 4:35 PM
> To: Hoang Vo 
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 1 of 1] cpsv: To update checkpoint user number for 
> each node [#1669] V4
>
> Hi Hoang ,
>
> Please hold on pushing.
>
> On new node we have see some issue please check CPD enode and decode 
> once ( new patch node ) .
>
> Aug  9 14:23:01 SC-1 osafckptd[20478]: hj_enc.c:311:
> decode_flatten_space: Assertion 'p8' failed.
> Aug  9 14:23:01 SC-1 osafamfnd[20439]: NO 
> 'safComp=CPD,safSu=SC-1,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown'
:
> Recovery is 'nodeFailfast'
>
> -AVM
>
>
>
> On 8/9/2016 2:09 PM, A V Mahesh wrote:
>> ACK,
>>
>> -AVM
>>
>>
>> On 8/3/2016 4:02 PM, Hoang Vo wrote:
>>>osaf/libs/common/cpsv/include/cpd_cb.h |2 +
>>>osaf/libs/common/cpsv/include/cpd_proc.h |3 +
>>>osaf/libs/common/cpsv/include/cpd_red.h  |   13 ++
>>>osaf/libs/common/cpsv/include/cpsv_evt.h |8 +
>>>osaf/services/saf/cpsv/cpd/cpd_db.c  |   14 ++-
>>>osaf/services/saf/cpsv/cpd/cpd_evt.c |8 +
>>>osaf/services/saf/cpsv/cpd/cpd_mbcsv.c   |   96 ---
>>>osaf/services/saf/cpsv/cpd/cpd_proc.c|  148
>>> +++
>>>osaf/services/saf/cpsv/cpd/cpd_red.c |   30 -
>>>osaf/services/saf/cpsv/cpd/cpd_sbevt.c   |   57 +--
>>>10 files changed, 344 insertions(+), 35 deletions(-)
>>>
>>>
>>> Problem:
>>> ---
>>> The saCkptCheckpointNumOpeners is not updated when a node which has 
>>> a checkpoint client restarts.
>>>
>>> Solution:
>>> 
>>> Currently CPD doesn't store number of user on each node. This patch 
>>> updates CPD to update information about users on each node for each 
>>> checkpoint. When a node restarts, the CPD update the total number of 
>>> users for a checkpoint accordingly. This is reflected on 
>>> saCkptCheckpointNumOpeners attribute correctly.
>>>
>>> diff --git a/osaf/libs/common/cpsv/include/cpd_cb.h
>>> b/osaf/libs/common/cpsv/include/cpd_cb.h
>>> --- a/osaf/libs/common/cpsv/include/cpd_cb.h
>>> +++ b/osaf/libs/common/cpsv/include/cpd_cb.h
>>> @@ -92,6 +92,8 @@ typedef struct cpd_ckpt_info_node {
>>>uint32_t num_users;
>>>uint32_t num_readers;
>>>uint32_t num_writers;
>>> +uint32_t node_users_cnt;
>>> +CPD_NODE_USER_INFO *node_users;
>>>  /* for imm */
>>>SaUint32T ckpt_used_size;
>>> diff --git a/osaf/libs/common/cpsv/include/cpd_proc.h
>>> b/osaf/libs/common/cpsv/include/cpd_proc.h
>>> --- a/osaf/libs/common/cpsv/include/cpd_proc.h
>>> +++ b/osaf/libs/common/cpsv/include/cpd_proc.h
>>> @@ -108,5 +108,8 @@ uint32_t cpd_mbcsv_enc_async_update(CPD_
>>>uint32_t cpd_mbcsv_close(CPD_CB *cb);
>>>bool cpd_is_noncollocated_replica_present_on_payload(CPD_CB *cb, 
>>> CPD_CKPT_INFO_NODE *ckpt_node);
>>>uint32_t cpd_ckpt_reploc_imm_object_delete(CPD_CB *cb, 
>>> CPD_CKPT_REPLOC_INFO *ckpt_reploc_node ,bool is_unlink_set);
>>> +void cpd_proc_increase_node_user_info(CPD_CKPT_INFO_NODE 
>>> +*ckpt_node,
>>> MDS_DEST cpnd_dest, SaCkptCheckpointOpenFlagsT open_flags);
>>> +void cpd_proc_decrease_node_user_info(CPD_CKPT_INFO_NODE 
>>> +*ckpt_node,
>>> MDS_DEST cpnd_dest, SaCkptCheckpointOpenFlagsT open_flags);
>>> +void cpd_proc_update_user_info_when_node_down(CPD_CB *cb, NODE_ID
>>> node_id);
>>>uint32_t cpd_proc_ckpt_update_post(CPD_CB *cb);
>>>#endif
>>> diff --git a/osaf/libs/common/cpsv/include/cpd_red.h
>>> b/osaf/libs/common/cpsv/include/cpd_red.h
>>> --- a/osaf/libs/common/cpsv/include/cpd_red.h
>>> +++ b/osaf/libs/common/cpsv/include/cpd_red.h
>>> @@ -64,6 +64,18 @@ typedef struct cpd_a2s_ckpt_usr_info {
>>>  } CPD_A2S_CKPT_USR_INFO;
>>>+typedef struct cpd_a2s_ckpt_usr_info_2 {
>>> +SaCkptCheckpointHandleT ckpt_id;
>>> +uint32_t num_user;
>>> +uint32_t num_writer;
>>> +uint32_t num_reader;
>>> +uint32_t num_sections;
>>> +uint32_t ckpt_on_scxb1;
>>> +uint32_t ckpt_on_scxb2;
>>> +uint32_t node_users_cnt;
>>> +CPD_NODE_USER_INFO *node_list;
>>> +} CPD_A2S_CKPT_USR_INFO_2;
>>> +
>>>typedef struct cpd_mbcsv

Re: [devel] [PATCH 0 of 2] Review Request for AMF: Support admin operation continuation after headless [#1725 Part 1] V2

2016-08-11 Thread minh chau
Hi Nagu, Praveen,

Can you please give me comments if you have any so far, that would help 
me revise some codes first while you can continue reviewing?
There are some changes in SG codes, I hope it doesn't break the SG's 
existing logic.

Thanks,
Minh

On 05/08/16 07:20, Minh Hon Chau wrote:
> Summary: AMF: Support admin operation continuation after headless [#1725 Part 
> 1] V2
> Review request for Trac Ticket(s): 1725
> Peer Reviewer(s): AMF devs
> Pull request to: <>
> Affected branch(es): default
> Development branch: default
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
> This V2 avoid AMFD crash if scAbsence is not configured.
> V2's diff (from V1) is at avd_process_state_info_queue()
>
> changeset 2215120caf950daa78927142aadebc27fda9d8b4
> Author:   Minh Hon Chau 
> Date: Fri, 05 Aug 2016 07:13:09 +1000
>
>   AMFD: Introduce new RTA states for admin operation continuation after
>   headless [#1725 part 1] V2
>
>   If there's an admin operation running and at that time cluster goes into
>   headless stage, the normal admin operation sequence is interrupted. 
> Since
>   both SCs are down, the SI assignments at AMFND could be on going or
>   completed during headless period. After headless this admin operation 
> should
>   be continued. This patch series supports the admin operation 
> continuation
>   after headless.
>
>   To resume the admin operation after headless, the states need to be 
> restored
>   are: SUSI fsm states, SG fsm states, SI Dependency states (not 
> suppported in
>   this patch), and SU operation list in SG at the time cluster goes 
> headless.
>
>   At this moment, the SG fsm states are set variously in each specific SG
>   models. Also, the rule that a SU to be added in SG's operation list is 
> not
>   consistent. A SU is added to operation list after AMFD sends 
> su_si_assign
>   event on this SU in most of the places. However, there're are some 
> scenarios
>   that a SU is added to the list for other purposes. These difficulties 
> make
>   the state logic deduction hard to implemenent.
>
>   This patch introduces new RTA states: saAmfSGSuOperationList,
>   saAmfSGFsmState, saAmfSISUFsmState to capture the SG's operation list, 
> SG
>   Fsm state, SUSI fsm state in AMFD's memory to IMM during AMFD's 
> lifetime. If
>   cluster comes back from headless, these RTA will read from IMM to 
> restore
>   states in AMFD's memory. After this patch, if admin operation 
> interrupts to
>   headless stage, and csi callback is responded after headless, the admin
>   operation can continue. The other patch in this series will help admin
>   operation continuation if a csi callback completes during headless.
>
> changeset 7a016215ab72d6a8a6e66c2cbd55c8cd3d15c3f9
> Author:   Minh Hon Chau 
> Date: Fri, 05 Aug 2016 07:13:09 +1000
>
>   AMFND: Admin operation continuation if csi callback completes during
>   headless [#1725 part 1] V1
>
>   The patch buffers susi_resp_msg during headless stage and resend it to 
> AMFD
>   after headless.
>
>
> Complete diffstat:
> --
>   osaf/services/saf/amf/amfd/cluster.cc |4 +
>   osaf/services/saf/amf/amfd/csi.cc |   38 
>   osaf/services/saf/amf/amfd/imm.cc |5 +-
>   osaf/services/saf/amf/amfd/include/csi.h  |1 -
>   osaf/services/saf/amf/amfd/include/imm.h  |5 +-
>   osaf/services/saf/amf/amfd/include/sg.h   |6 +-
>   osaf/services/saf/amf/amfd/include/su.h   |3 +-
>   osaf/services/saf/amf/amfd/include/susi.h |6 +-
>   osaf/services/saf/amf/amfd/include/util.h |2 +
>   osaf/services/saf/amf/amfd/ndfsm.cc   |   11 ++-
>   osaf/services/saf/amf/amfd/role.cc|6 -
>   osaf/services/saf/amf/amfd/sg.cc  |  110 
> +-
>   osaf/services/saf/amf/amfd/sg_2n_fsm.cc   |8 +-
>   osaf/services/saf/amf/amfd/sg_npm_fsm.cc  |2 +-
>   osaf/services/saf/amf/amfd/sg_nwayact_fsm.cc  |2 +-
>   osaf/services/saf/amf/amfd/sgproc.cc  |  140 
> +--
>   osaf/services/saf/amf/amfd/siass.cc   |  204 
> --
>   osaf/services/saf/amf/amfd/su.cc  |   46 +-
>   osaf/services/saf/amf/amfnd/di.cc |  199 
> ++---
>   osaf/services/saf/amf/

Re: [devel] [PATCH 6 of 8] cpsv: Apply new messages supporting extended SaNameT to CPD, CPND, and CPA v1 [#1574]

2016-08-11 Thread A V Mahesh
Hi Hoang,

We don't required any new event like CPND_EVT_D2ND_CKPT_CREATE_2
even though NEW CPND might might be sending event to OLD CPD.

In general Opensaf rule is that any newly introduce enhancement/feature 
functionality can be used
once Cluster is completely upgraded to new  version.So while upgrading 
(in-service )
the  SA_ENABLE_EXTENDED_NAMES  will be false  ( longDnsAllowed=0
of opensafImm=opensafImm,safApp=safImmService)  , once clusters upgraded 
to new version then only
ongDnsAllowed set to 1, ("immcfg -o safImmService -m 
opensafImm=opensafImm,safApp=safImmService -a longDnsAllowed=1")
so remove new event merge the content in to a single  exist old event , 
and do additionl functonality  based on the state of longDnsAllowed=1 or 0

-AVM

On 7/21/2016 3:04 PM, Hoang Vo wrote:
>   osaf/libs/agents/saf/cpa/cpa_api.c  |  12 +---
>   osaf/libs/agents/saf/cpa/cpa_mds.c  |   2 +-
>   osaf/libs/common/cpsv/cpsv_evt.c|   1 +
>   osaf/services/saf/cpsv/cpd/cpd_evt.c|  10 +++---
>   osaf/services/saf/cpsv/cpd/cpd_mds.c|   3 ++-
>   osaf/services/saf/cpsv/cpd/cpd_proc.c   |   2 +-
>   osaf/services/saf/cpsv/cpnd/cpnd_evt.c  |  26 --
>   osaf/services/saf/cpsv/cpnd/cpnd_mds.c  |   4 ++--
>   osaf/services/saf/cpsv/cpnd/cpnd_proc.c |   6 +++---
>   9 files changed, 42 insertions(+), 24 deletions(-)
>
>
> diff --git a/osaf/libs/agents/saf/cpa/cpa_api.c 
> b/osaf/libs/agents/saf/cpa/cpa_api.c
> --- a/osaf/libs/agents/saf/cpa/cpa_api.c
> +++ b/osaf/libs/agents/saf/cpa/cpa_api.c
> @@ -880,6 +880,8 @@ SaAisErrorT saCkptCheckpointOpen(SaCkptH
>   }
>   
>   ckpt_name = osaf_extended_name_borrow(checkpointName);
> + if (strlen(ckpt_name) >= kOsafMaxDnLength)
> + return SA_AIS_ERR_INVALID_PARAM;
>   
>   /* SA_AIS_ERR_INVALID_PARAM, bullet 4 in SAI-AIS-CKPT-B.02.02
>  Section 3.6.1 saCkptCheckpointOpen() and 
> saCkptCheckpointOpenAsync(), Return Values */
> @@ -981,7 +983,7 @@ SaAisErrorT saCkptCheckpointOpen(SaCkptH
>   /* Populate & Send the Open Event to CPND */
>   memset(&evt, 0, sizeof(CPSV_EVT));
>   evt.type = CPSV_EVT_TYPE_CPND;
> - evt.info.cpnd.type = CPND_EVT_A2ND_CKPT_OPEN;
> + evt.info.cpnd.type = CPND_EVT_A2ND_CKPT_OPEN_2;
>   evt.info.cpnd.info.openReq.client_hdl = ckptHandle;
>   evt.info.cpnd.info.openReq.lcl_ckpt_hdl = lc_node->lcl_ckpt_hdl;
>   
> @@ -1192,6 +1194,8 @@ SaAisErrorT saCkptCheckpointOpenAsync(Sa
>   }
>   
>   ckpt_name = osaf_extended_name_borrow(checkpointName);
> + if (strlen(ckpt_name) >= kOsafMaxDnLength)
> + return SA_AIS_ERR_INVALID_PARAM;
>   
>   /* SA_AIS_ERR_INVALID_PARAM, bullet 4 in SAI-AIS-CKPT-B.02.02
>  Section 3.6.1 saCkptCheckpointOpen() and 
> saCkptCheckpointOpenAsync(), Return Values */
> @@ -1277,7 +1281,7 @@ SaAisErrorT saCkptCheckpointOpenAsync(Sa
>   /* Populate & Send the Open Event to CPND */
>   memset(&evt, 0, sizeof(CPSV_EVT));
>   evt.type = CPSV_EVT_TYPE_CPND;
> - evt.info.cpnd.type = CPND_EVT_A2ND_CKPT_OPEN;
> + evt.info.cpnd.type = CPND_EVT_A2ND_CKPT_OPEN_2;
>   evt.info.cpnd.info.openReq.client_hdl = ckptHandle;
>   evt.info.cpnd.info.openReq.lcl_ckpt_hdl = lc_node->lcl_ckpt_hdl;
>   
> @@ -1597,6 +1601,8 @@ SaAisErrorT saCkptCheckpointUnlink(SaCkp
>   }
>   
>   ckpt_name = osaf_extended_name_borrow(checkpointName);
> + if (strlen(ckpt_name) >= kOsafMaxDnLength)
> + return SA_AIS_ERR_INVALID_PARAM;
>   
>   /* retrieve CPA CB */
>   m_CPA_RETRIEVE_CB(cb);
> @@ -1635,7 +1641,7 @@ SaAisErrorT saCkptCheckpointUnlink(SaCkp
>   /* Populate evt.info.cpnd.info.unlinkReq & Call MDS sync Send */
>   memset(&evt, 0, sizeof(CPSV_EVT));
>   evt.type = CPSV_EVT_TYPE_CPND;
> - evt.info.cpnd.type = CPND_EVT_A2ND_CKPT_UNLINK;
> + evt.info.cpnd.type = CPND_EVT_A2ND_CKPT_UNLINK_2;
>   
>   osaf_extended_name_lend(ckpt_name, 
> &evt.info.cpnd.info.ulinkReq.ckpt_name);
>   
> diff --git a/osaf/libs/agents/saf/cpa/cpa_mds.c 
> b/osaf/libs/agents/saf/cpa/cpa_mds.c
> --- a/osaf/libs/agents/saf/cpa/cpa_mds.c
> +++ b/osaf/libs/agents/saf/cpa/cpa_mds.c
> @@ -515,7 +515,7 @@ static uint32_t cpa_mds_svc_evt(CPA_CB *
>  /* Populate & Send the Open Event to CPND */
>  memset(&evt, 0, sizeof(CPSV_EVT));
>  evt.type = CPSV_EVT_TYPE_CPND;
> -evt.info.cpnd.type = CPND_EVT_A2ND_CKPT_LIST_UPDATE;
> +evt.info.cpnd.type = CPND_EVT_A2ND_CKPT_LIST_UPDATE_2;
>  evt.info.cpnd.info.ckptListUpdate.client_hdl = 
> lc_node->cl_hdl;
>  osaf_extended_name_lend(lc_node->ckpt_name, 
> &evt.info.cpnd.info.ckptListUpdate.ckpt_name);
>   
> diff --git a/osaf/libs/common/cpsv/cpsv_evt.c 
> b/osaf/libs/common/cpsv/cpsv_evt.c
> --- a/osaf/libs/common/cpsv/cpsv_evt.c
> +++ b/osaf/libs/common/cpsv/cpsv_evt.c
> @@ -2414,6 +2414,7 @@ uint32_t cps

Re: [devel] [PATCH 4 of 8] cpsv: Add new message to support extended SaNameT v1 [#1574]

2016-08-11 Thread A V Mahesh
Hi Hoang,

I completed the testing most of the in service & normal test case are 
working fine ,
so I stated reviewing code now can please answer below :

1)
This patch introduced multiple new event  between  Agent to ND which are 
always
local to the node (  in a new version software  cpa & cpnd will always 
co-exist )
their no concept OLD CPA communicating with NEW CPND , so it is not 
required introduce new event
we can alwasy make exist event compatible with new support extended 
SaNameT ,
so remove new event merge the content in to a single  exist old event .

=

/* Events support extended SaNameT */
CPND_EVT_A2ND_CKPT_OPEN_2,/* Checkpoint Open Request */
CPND_EVT_A2ND_CKPT_UNLINK_2,/* Checkpoint Unlink Call */
CPND_EVT_A2ND_CKPT_LIST_UPDATE_2,/* Checkpoint ckpt list update Call */
CPND_EVT_D2ND_CKPT_CREATE_2,/* ckpt create evt for Non-collocated */

=

-AVM

On 7/21/2016 3:04 PM, Hoang Vo wrote:
>   osaf/libs/common/cpsv/cpsv_evt.c |  504 
> ++-
>   osaf/libs/common/cpsv/include/cpsv_evt.h |   24 +
>   osaf/services/saf/cpsv/cpd/cpd_mds.c |   84 -
>   osaf/services/saf/cpsv/cpnd/cpnd_mds.c   |   84 -
>   4 files changed, 668 insertions(+), 28 deletions(-)
>
>
> New messages supporting extended SaNameT are introduce. Encoding and decoding 
> funtions for them are also included.
>
> diff --git a/osaf/libs/common/cpsv/cpsv_evt.c 
> b/osaf/libs/common/cpsv/cpsv_evt.c
> --- a/osaf/libs/common/cpsv/cpsv_evt.c
> +++ b/osaf/libs/common/cpsv/cpsv_evt.c
> @@ -30,11 +30,14 @@
>   
>   #include "cpsv.h"
>   #include "cpa_tmr.h"
> +#include "osaf_extended_name.h"
>   
>   FUNC_DECLARATION(CPSV_CKPT_DATA);
>   static SaCkptSectionIdT *cpsv_evt_dec_sec_id(NCS_UBAID *i_ub, uint32_t 
> svc_id);
>   static uint32_t cpsv_evt_enc_sec_id(NCS_UBAID *o_ub, SaCkptSectionIdT 
> *sec_id);
>   static void cpsv_convert_sec_id_to_string(char *sec_id_str, 
> SaCkptSectionIdT *section_id);
> +static uint32_t cpsv_encode_extended_name_flat(NCS_UBAID *uba, SaNameT 
> *name);
> +static uint32_t cpsv_decode_extended_name_flat(NCS_UBAID *uba, SaNameT 
> *name);
>   
>   const char *cpa_evt_str[] = {
>   "STRING_0",
> @@ -258,6 +261,13 @@ char* cpsv_evt_str(CPSV_EVT *evt, char *
>   info->client_hdl, info->ckpt_name.value);
>   break;
>   }
> + case CPND_EVT_A2ND_CKPT_OPEN_2:
> + {
> + CPSV_A2ND_OPEN_REQ *info = &evt->info.cpnd.info.openReq;
> + snprintf(o_evt_str, len, 
> "CPND_EVT_A2ND_CKPT_OPEN_2(hdl=%llu, %s)",
> + info->client_hdl, 
> osaf_extended_name_borrow(&info->ckpt_name));
> + break;
> + }
>   case CPND_EVT_A2ND_CKPT_CLOSE:
>   {
>   CPSV_A2ND_CKPT_CLOSE *info = 
> &evt->info.cpnd.info.closeReq;
> @@ -271,6 +281,12 @@ char* cpsv_evt_str(CPSV_EVT *evt, char *
>   snprintf(o_evt_str, len, 
> "CPND_EVT_A2ND_CKPT_UNLINK(%s)", info->ckpt_name.value);
>   break;
>   }
> + case CPND_EVT_A2ND_CKPT_UNLINK_2:
> + {
> + CPSV_A2ND_CKPT_UNLINK *info = 
> &evt->info.cpnd.info.ulinkReq;
> + snprintf(o_evt_str, len, 
> "CPND_EVT_A2ND_CKPT_UNLINK_2(%s)", 
> osaf_extended_name_borrow(&info->ckpt_name));
> + break;
> + }
>   case CPND_EVT_A2ND_CKPT_RDSET:
>   {
>   CPSV_A2ND_RDSET *info = &evt->info.cpnd.info.rdsetReq;
> @@ -513,12 +529,33 @@ char* cpsv_evt_str(CPSV_EVT *evt, char *
>   case CPND_EVT_D2ND_CKPT_CREATE:
>   {
>   CPSV_D2ND_CKPT_CREATE *info = 
> &evt->info.cpnd.info.ckpt_create;
> - snprintf(o_evt_str, len, "[%llu] 
> CPND_EVT_D2ND_CKPT_CREATE(%s, create_rep=%s, active=0x%X)",
> - info->ckpt_info.ckpt_id, info->ckpt_name.value,
> + snprintf(o_evt_str, len, "[%llu] 
> CPND_EVT_D2ND_CKPT_CREATE(%s, create_rep=%s, is_act=%s, active=0x%X, 
> dest_cnt=%d)",
> + info->ckpt_info.ckpt_id, 
> osaf_extended_name_borrow(&info->ckpt_name),
>   info->ckpt_info.ckpt_rep_create ? "true" : 
> "false",
> - 
> m_NCS_NODE_ID_FROM_MDS_DEST(info->ckpt_info.active_dest));
> + info->ckpt_info.is_active_exists ? "true" : 
> "false",
> + 
> m_NCS_NODE_ID_FROM_MDS_DEST(info->ckpt_info.active_dest),
> + info->ckpt_info.dest_cnt);
>   break;
>   }
> + case CPND_EVT_D2ND_CKPT_CREATE_2:
> + {
> + 

Re: [devel] [PATCH 1 of 1] cpsv: To update checkpoint user number for each node [#1669] V4

2016-08-11 Thread A V Mahesh
I will test for you send the patch.

-AVM


On 8/11/2016 3:38 PM, Vo Minh Hoang wrote:
> Dear Mahesh,
>
> Would you please tell me the case that produce this error?
> I review source code and found that encode/decode function missed 1
> attribute.
> But running test in our environment could not reproduce this problem.
>
> Thank you and best regards,
> Hoang
>
> -Original Message-
> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
> Sent: Tuesday, August 9, 2016 4:35 PM
> To: Hoang Vo 
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 1 of 1] cpsv: To update checkpoint user number for each
> node [#1669] V4
>
> Hi Hoang ,
>
> Please hold on pushing.
>
> On new node we have see some issue please check CPD enode and decode once (
> new patch node ) .
>
> Aug  9 14:23:01 SC-1 osafckptd[20478]: hj_enc.c:311:
> decode_flatten_space: Assertion 'p8' failed.
> Aug  9 14:23:01 SC-1 osafamfnd[20439]: NO
> 'safComp=CPD,safSu=SC-1,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown' :
> Recovery is 'nodeFailfast'
>
> -AVM
>
>
>
> On 8/9/2016 2:09 PM, A V Mahesh wrote:
>> ACK,
>>
>> -AVM
>>
>>
>> On 8/3/2016 4:02 PM, Hoang Vo wrote:
>>>osaf/libs/common/cpsv/include/cpd_cb.h |2 +
>>>osaf/libs/common/cpsv/include/cpd_proc.h |3 +
>>>osaf/libs/common/cpsv/include/cpd_red.h  |   13 ++
>>>osaf/libs/common/cpsv/include/cpsv_evt.h |8 +
>>>osaf/services/saf/cpsv/cpd/cpd_db.c  |   14 ++-
>>>osaf/services/saf/cpsv/cpd/cpd_evt.c |8 +
>>>osaf/services/saf/cpsv/cpd/cpd_mbcsv.c   |   96 ---
>>>osaf/services/saf/cpsv/cpd/cpd_proc.c|  148
>>> +++
>>>osaf/services/saf/cpsv/cpd/cpd_red.c |   30 -
>>>osaf/services/saf/cpsv/cpd/cpd_sbevt.c   |   57 +--
>>>10 files changed, 344 insertions(+), 35 deletions(-)
>>>
>>>
>>> Problem:
>>> ---
>>> The saCkptCheckpointNumOpeners is not updated when a node which has a
>>> checkpoint client restarts.
>>>
>>> Solution:
>>> 
>>> Currently CPD doesn't store number of user on each node. This patch
>>> updates CPD to update information about users on each node for each
>>> checkpoint. When a node restarts, the CPD update the total number of
>>> users for a checkpoint accordingly. This is reflected on
>>> saCkptCheckpointNumOpeners attribute correctly.
>>>
>>> diff --git a/osaf/libs/common/cpsv/include/cpd_cb.h
>>> b/osaf/libs/common/cpsv/include/cpd_cb.h
>>> --- a/osaf/libs/common/cpsv/include/cpd_cb.h
>>> +++ b/osaf/libs/common/cpsv/include/cpd_cb.h
>>> @@ -92,6 +92,8 @@ typedef struct cpd_ckpt_info_node {
>>>uint32_t num_users;
>>>uint32_t num_readers;
>>>uint32_t num_writers;
>>> +uint32_t node_users_cnt;
>>> +CPD_NODE_USER_INFO *node_users;
>>>  /* for imm */
>>>SaUint32T ckpt_used_size;
>>> diff --git a/osaf/libs/common/cpsv/include/cpd_proc.h
>>> b/osaf/libs/common/cpsv/include/cpd_proc.h
>>> --- a/osaf/libs/common/cpsv/include/cpd_proc.h
>>> +++ b/osaf/libs/common/cpsv/include/cpd_proc.h
>>> @@ -108,5 +108,8 @@ uint32_t cpd_mbcsv_enc_async_update(CPD_
>>>uint32_t cpd_mbcsv_close(CPD_CB *cb);
>>>bool cpd_is_noncollocated_replica_present_on_payload(CPD_CB *cb,
>>> CPD_CKPT_INFO_NODE *ckpt_node);
>>>uint32_t cpd_ckpt_reploc_imm_object_delete(CPD_CB *cb,
>>> CPD_CKPT_REPLOC_INFO *ckpt_reploc_node ,bool is_unlink_set);
>>> +void cpd_proc_increase_node_user_info(CPD_CKPT_INFO_NODE *ckpt_node,
>>> MDS_DEST cpnd_dest, SaCkptCheckpointOpenFlagsT open_flags);
>>> +void cpd_proc_decrease_node_user_info(CPD_CKPT_INFO_NODE *ckpt_node,
>>> MDS_DEST cpnd_dest, SaCkptCheckpointOpenFlagsT open_flags);
>>> +void cpd_proc_update_user_info_when_node_down(CPD_CB *cb, NODE_ID
>>> node_id);
>>>uint32_t cpd_proc_ckpt_update_post(CPD_CB *cb);
>>>#endif
>>> diff --git a/osaf/libs/common/cpsv/include/cpd_red.h
>>> b/osaf/libs/common/cpsv/include/cpd_red.h
>>> --- a/osaf/libs/common/cpsv/include/cpd_red.h
>>> +++ b/osaf/libs/common/cpsv/include/cpd_red.h
>>> @@ -64,6 +64,18 @@ typedef struct cpd_a2s_ckpt_usr_info {
>>>  } CPD_A2S_CKPT_USR_INFO;
>>>+typedef struct cpd_a2s_ckpt_usr_info_2 {
>>> +SaCkptCheckpointHandleT ckpt_id;
>>> +uint32_t num_user;
>>> +uint32_t num_writer;
>>> +uint32_t num_reader;
>>> +uint32_t num_sections;
>>> +uint32_t ckpt_on_scxb1;
>>> +uint32_t ckpt_on_scxb2;
>>> +uint32_t node_users_cnt;
>>> +CPD_NODE_USER_INFO *node_list;
>>> +} CPD_A2S_CKPT_USR_INFO_2;
>>> +
>>>typedef struct cpd_mbcsv_msg {
>>>CPD_MBCSV_MSG_TYPE type;
>>>union {
>>> @@ -76,6 +88,7 @@ typedef struct cpd_mbcsv_msg {
>>>CPD_A2S_CKPT_UNLINK ckpt_ulink;
>>>CPD_A2S_CKPT_USR_INFO usr_info;
>>>CPSV_CKPT_DEST_INFO dest_down;
>>> +CPD_A2S_CKPT_USR_INFO_2 usr_info_2;
>>>} info;
>>>} CPD_MBCSV_MSG;
>>>diff --git a/osaf/libs/common/cpsv/include/cpsv_evt.h
>>> b/osaf/libs/common/cpsv/include/cps

Re: [devel] [PATCH 1 of 1] fm: Enabling remote fencing is not correct [#1949]

2016-08-11 Thread Mathivanan Naickan Palanivelu
ACK,
Mathi

> -Original Message-
> From: Hans Nordeback [mailto:hans.nordeb...@ericsson.com]
> Sent: Thursday, August 11, 2016 2:38 PM
> To: anders.wid...@ericsson.com; Mathivanan Naickan Palanivelu
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] fm: Enabling remote fencing is not correct [#1949]
> 
>  osaf/services/infrastructure/fm/fms/fm_main.c |  9 +++--
>  1 files changed, 7 insertions(+), 2 deletions(-)
> 
> 
> diff --git a/osaf/services/infrastructure/fm/fms/fm_main.c
> b/osaf/services/infrastructure/fm/fms/fm_main.c
> --- a/osaf/services/infrastructure/fm/fms/fm_main.c
> +++ b/osaf/services/infrastructure/fm/fms/fm_main.c
> @@ -401,8 +401,13 @@ static uint32_t fm_get_args(FM_CB *fm_cb
>   fm_cb->use_remote_fencing = false;
>   use_remote_fencing = getenv("FMS_USE_REMOTE_FENCING");
>   if (use_remote_fencing != NULL) {
> - fm_cb->use_remote_fencing = true;
> - LOG_NO("Remote fencing is enabled");
> + int use_fencing = strtol(use_remote_fencing, NULL, 10);
> + if (use_fencing == 1) {
> + fm_cb->use_remote_fencing = true;
> + LOG_NO("Remote fencing is enabled");
> + } else {
> + LOG_NO("Remote fencing is disabled");
> + }
>   }
> 
>   value = getenv("EE_ID");

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


Re: [devel] [PATCH 1 of 1] cpsv: To update checkpoint user number for each node [#1669] V4

2016-08-11 Thread Vo Minh Hoang
Dear Mahesh,

Would you please tell me the case that produce this error?
I review source code and found that encode/decode function missed 1
attribute.
But running test in our environment could not reproduce this problem.

Thank you and best regards,
Hoang

-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com] 
Sent: Tuesday, August 9, 2016 4:35 PM
To: Hoang Vo 
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] cpsv: To update checkpoint user number for each
node [#1669] V4

Hi Hoang ,

Please hold on pushing.

On new node we have see some issue please check CPD enode and decode once (
new patch node ) .

Aug  9 14:23:01 SC-1 osafckptd[20478]: hj_enc.c:311: 
decode_flatten_space: Assertion 'p8' failed.
Aug  9 14:23:01 SC-1 osafamfnd[20439]: NO
'safComp=CPD,safSu=SC-1,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown' :
Recovery is 'nodeFailfast'

-AVM



On 8/9/2016 2:09 PM, A V Mahesh wrote:
> ACK,
>
> -AVM
>
>
> On 8/3/2016 4:02 PM, Hoang Vo wrote:
>>   osaf/libs/common/cpsv/include/cpd_cb.h |2 +
>>   osaf/libs/common/cpsv/include/cpd_proc.h |3 +
>>   osaf/libs/common/cpsv/include/cpd_red.h  |   13 ++
>>   osaf/libs/common/cpsv/include/cpsv_evt.h |8 +
>>   osaf/services/saf/cpsv/cpd/cpd_db.c  |   14 ++-
>>   osaf/services/saf/cpsv/cpd/cpd_evt.c |8 +
>>   osaf/services/saf/cpsv/cpd/cpd_mbcsv.c   |   96 ---
>>   osaf/services/saf/cpsv/cpd/cpd_proc.c|  148 
>> +++
>>   osaf/services/saf/cpsv/cpd/cpd_red.c |   30 -
>>   osaf/services/saf/cpsv/cpd/cpd_sbevt.c   |   57 +--
>>   10 files changed, 344 insertions(+), 35 deletions(-)
>>
>>
>> Problem:
>> ---
>> The saCkptCheckpointNumOpeners is not updated when a node which has a 
>> checkpoint client restarts.
>>
>> Solution:
>> 
>> Currently CPD doesn't store number of user on each node. This patch 
>> updates CPD to update information about users on each node for each 
>> checkpoint. When a node restarts, the CPD update the total number of 
>> users for a checkpoint accordingly. This is reflected on 
>> saCkptCheckpointNumOpeners attribute correctly.
>>
>> diff --git a/osaf/libs/common/cpsv/include/cpd_cb.h
>> b/osaf/libs/common/cpsv/include/cpd_cb.h
>> --- a/osaf/libs/common/cpsv/include/cpd_cb.h
>> +++ b/osaf/libs/common/cpsv/include/cpd_cb.h
>> @@ -92,6 +92,8 @@ typedef struct cpd_ckpt_info_node {
>>   uint32_t num_users;
>>   uint32_t num_readers;
>>   uint32_t num_writers;
>> +uint32_t node_users_cnt;
>> +CPD_NODE_USER_INFO *node_users;
>> /* for imm */
>>   SaUint32T ckpt_used_size;
>> diff --git a/osaf/libs/common/cpsv/include/cpd_proc.h
>> b/osaf/libs/common/cpsv/include/cpd_proc.h
>> --- a/osaf/libs/common/cpsv/include/cpd_proc.h
>> +++ b/osaf/libs/common/cpsv/include/cpd_proc.h
>> @@ -108,5 +108,8 @@ uint32_t cpd_mbcsv_enc_async_update(CPD_
>>   uint32_t cpd_mbcsv_close(CPD_CB *cb);
>>   bool cpd_is_noncollocated_replica_present_on_payload(CPD_CB *cb, 
>> CPD_CKPT_INFO_NODE *ckpt_node);
>>   uint32_t cpd_ckpt_reploc_imm_object_delete(CPD_CB *cb, 
>> CPD_CKPT_REPLOC_INFO *ckpt_reploc_node ,bool is_unlink_set);
>> +void cpd_proc_increase_node_user_info(CPD_CKPT_INFO_NODE *ckpt_node,
>> MDS_DEST cpnd_dest, SaCkptCheckpointOpenFlagsT open_flags);
>> +void cpd_proc_decrease_node_user_info(CPD_CKPT_INFO_NODE *ckpt_node,
>> MDS_DEST cpnd_dest, SaCkptCheckpointOpenFlagsT open_flags);
>> +void cpd_proc_update_user_info_when_node_down(CPD_CB *cb, NODE_ID
>> node_id);
>>   uint32_t cpd_proc_ckpt_update_post(CPD_CB *cb);
>>   #endif
>> diff --git a/osaf/libs/common/cpsv/include/cpd_red.h
>> b/osaf/libs/common/cpsv/include/cpd_red.h
>> --- a/osaf/libs/common/cpsv/include/cpd_red.h
>> +++ b/osaf/libs/common/cpsv/include/cpd_red.h
>> @@ -64,6 +64,18 @@ typedef struct cpd_a2s_ckpt_usr_info {
>> } CPD_A2S_CKPT_USR_INFO;
>>   +typedef struct cpd_a2s_ckpt_usr_info_2 {
>> +SaCkptCheckpointHandleT ckpt_id;
>> +uint32_t num_user;
>> +uint32_t num_writer;
>> +uint32_t num_reader;
>> +uint32_t num_sections;
>> +uint32_t ckpt_on_scxb1;
>> +uint32_t ckpt_on_scxb2;
>> +uint32_t node_users_cnt;
>> +CPD_NODE_USER_INFO *node_list;
>> +} CPD_A2S_CKPT_USR_INFO_2;
>> +
>>   typedef struct cpd_mbcsv_msg {
>>   CPD_MBCSV_MSG_TYPE type;
>>   union {
>> @@ -76,6 +88,7 @@ typedef struct cpd_mbcsv_msg {
>>   CPD_A2S_CKPT_UNLINK ckpt_ulink;
>>   CPD_A2S_CKPT_USR_INFO usr_info;
>>   CPSV_CKPT_DEST_INFO dest_down;
>> +CPD_A2S_CKPT_USR_INFO_2 usr_info_2;
>>   } info;
>>   } CPD_MBCSV_MSG;
>>   diff --git a/osaf/libs/common/cpsv/include/cpsv_evt.h
>> b/osaf/libs/common/cpsv/include/cpsv_evt.h
>> --- a/osaf/libs/common/cpsv/include/cpsv_evt.h
>> +++ b/osaf/libs/common/cpsv/include/cpsv_evt.h
>> @@ -840,6 +840,14 @@ typedef struct cpd_tmr_info {
>>   } info;
>>   } CPD_TMR_INFO;
>>   +typedef struct cpd_node_user_info {
>> +MDS_DEST dest

[devel] [PATCH 1 of 1] fm: Enabling remote fencing is not correct [#1949]

2016-08-11 Thread Hans Nordeback
 osaf/services/infrastructure/fm/fms/fm_main.c |  9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)


diff --git a/osaf/services/infrastructure/fm/fms/fm_main.c 
b/osaf/services/infrastructure/fm/fms/fm_main.c
--- a/osaf/services/infrastructure/fm/fms/fm_main.c
+++ b/osaf/services/infrastructure/fm/fms/fm_main.c
@@ -401,8 +401,13 @@ static uint32_t fm_get_args(FM_CB *fm_cb
fm_cb->use_remote_fencing = false;
use_remote_fencing = getenv("FMS_USE_REMOTE_FENCING");
if (use_remote_fencing != NULL) {
-   fm_cb->use_remote_fencing = true;
-   LOG_NO("Remote fencing is enabled");
+   int use_fencing = strtol(use_remote_fencing, NULL, 10);
+   if (use_fencing == 1) {
+   fm_cb->use_remote_fencing = true;
+   LOG_NO("Remote fencing is enabled");
+   } else {
+   LOG_NO("Remote fencing is disabled");
+   }
}
 
value = getenv("EE_ID");

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 0 of 1] Review Request for fm: Enabling remote fencing is not correct [#1949]

2016-08-11 Thread Hans Nordeback
Summary: fm: Enabling remote fencing is not correct
Review request for Trac Ticket(s): #1949 
Peer Reviewer(s): AndersW, Mathi
Pull request to: 
Affected branch(es): default
Development branch: default


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-
 <>

changeset 8318f3a55cd553759172b96500ecd33d5cf9
Author: Hans Nordeback 
Date:   Thu, 11 Aug 2016 11:03:39 +0200

fm: Enabling remote fencing is not correct [#1949]


Complete diffstat:
--
 osaf/services/infrastructure/fm/fms/fm_main.c |  9 +++--
 1 files changed, 7 insertions(+), 2 deletions(-)


Testing Commands:
-
 <>


Testing, Expected Results:
--
 <>


Conditions of Submission:
-
 <>


Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  n  n
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] imm: Return implementer ID to timed out client [#1948]

2016-08-11 Thread Hung Nguyen
 osaf/services/saf/immsv/immnd/ImmModel.cc  |  12 ++--
 osaf/services/saf/immsv/immnd/immnd_evt.c  |   9 -
 osaf/services/saf/immsv/immnd/immnd_init.h |   2 +-
 3 files changed, 19 insertions(+), 4 deletions(-)


When receiving redundant request that comes from timed out client,
return SA_AIS_OK with the implementer ID.

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
@@ -1828,8 +1828,10 @@ immModel_implementerSet(IMMND_CB *cb, co
 }
 
 SaAisErrorT 
-immModel_implIsFree(IMMND_CB *cb, const SaImmOiImplementerNameT impName)
-{
+immModel_implIsFree(IMMND_CB *cb, const IMMSV_OI_IMPLSET_REQ *req, SaUint32T 
*impl_id)
+{
+*impl_id = 0;
+SaImmOiImplementerNameT impName = req->impl_name.buf;
 std::string implName(impName);
 if(implName.empty()) {
 LOG_NO("ERR_INVALID_PARAM: Empty implementer name");
@@ -1844,6 +1846,12 @@ immModel_implIsFree(IMMND_CB *cb, const 
 if(impl->mId == 0) {return SA_AIS_OK;}
 if(impl->mDying) {return SA_AIS_ERR_TRY_AGAIN;}
 
+/* Check for redundant request that comes from previously timed out client 
*/
+if (impl->mConn == m_IMMSV_UNPACK_HANDLE_HIGH(req->client_hdl) &&
+impl->mNodeId == m_IMMSV_UNPACK_HANDLE_LOW(req->client_hdl)) {
+*impl_id = impl->mId;
+}
+
 return SA_AIS_ERR_EXIST;
 }
 
diff --git a/osaf/services/saf/immsv/immnd/immnd_evt.c 
b/osaf/services/saf/immsv/immnd/immnd_evt.c
--- a/osaf/services/saf/immsv/immnd/immnd_evt.c
+++ b/osaf/services/saf/immsv/immnd/immnd_evt.c
@@ -2556,10 +2556,17 @@ static uint32_t immnd_evt_proc_impl_set(
in a subsequent implementerSet over fevs arriving before this 
implementerSet
arrives back over fevs. See finalizeSync #1871.
 */
+   SaUint32T impl_id;
send_evt.info.imma.info.implSetRsp.error =
-   immModel_implIsFree(cb, evt->info.implSet.impl_name.buf);
+   immModel_implIsFree(cb, &evt->info.implSet, &impl_id);
+
 
if(send_evt.info.imma.info.implSetRsp.error != SA_AIS_OK) {
+   if (impl_id && send_evt.info.imma.info.implSetRsp.error == 
SA_AIS_ERR_EXIST) {
+   /* Immediately respond OK to agent */
+   send_evt.info.imma.info.implSetRsp.error = SA_AIS_OK;
+   send_evt.info.imma.info.implSetRsp.implId = impl_id;
+   }
goto agent_rsp;
}
 
diff --git a/osaf/services/saf/immsv/immnd/immnd_init.h 
b/osaf/services/saf/immsv/immnd/immnd_init.h
--- a/osaf/services/saf/immsv/immnd/immnd_init.h
+++ b/osaf/services/saf/immsv/immnd/immnd_init.h
@@ -439,7 +439,7 @@ extern "C" {
bool immModel_pbeNotWritable(IMMND_CB *cb);
 
SaAisErrorT immModel_implIsFree(IMMND_CB *cb,
-   const SaImmOiImplementerNameT implName);
+   const IMMSV_OI_IMPLSET_REQ *req, SaUint32T *impl_id);
 
SaAisErrorT immModel_resourceDisplay(IMMND_CB *cb, 
const struct ImmsvAdminOperationParam *reqparams,

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 0 of 1] Review Request for imm: Return implementer ID to timed out client [#1948]

2016-08-11 Thread Hung Nguyen
Summary: imm: Return implementer ID to timed out client [#1948]
Review request for Trac Ticket(s): 1948
Peer Reviewer(s): Zoran, Neel
Pull request to:
Affected branch(es): 4.7, 5.0, 5.1
Development branch: 5.1


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-


changeset 343968c7fdfbc46dafff6a807c7c0279f97ad4e1
Author: Hung Nguyen 
Date:   Thu, 11 Aug 2016 13:51:52 +0700

imm: Return implementer ID to timed out client [#1948]

When receiving redundant request that comes from timed out client, 
return
SA_AIS_OK with the implementer ID.


Complete diffstat:
--
 osaf/services/saf/immsv/immnd/ImmModel.cc  |  12 ++--
 osaf/services/saf/immsv/immnd/immnd_evt.c  |   9 -
 osaf/services/saf/immsv/immnd/immnd_init.h |   2 +-
 3 files changed, 19 insertions(+), 4 deletions(-)


Testing Commands:
-



Testing, Expected Results:
--



Conditions of Submission:
-
Ack from reviewers.


Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  n  n
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 0 of 1] Review Request for ntfsv: refactor logging long dn notification [#1585] V2

2016-08-11 Thread Vu Minh Nguyen
Summary: ntfsv: refactor logging long dn notification [#1585]
Review request for Trac Ticket(s): #1585
Peer Reviewer(s): NTF maintainers
Pull request to: <>
Affected branch(es): Default
Development branch: Default


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesn
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   y
 Other   n


Comments (indicate scope for each "y" above):
-
 <>

changeset 46d54bc99a426693936ee6d21f5f0cd39bc70590
Author: Vu Minh Nguyen 
Date:   Fri, 22 Jul 2016 18:11:16 +0700

ntfsv: refactor logging long dn notification [#1585]

Remove the part of code that truncates the long DN. And update the long 
DN
test suite (#36) to make sure full record logged.


Complete diffstat:
--
 osaf/services/saf/ntfsv/ntfs/NtfLogger.cc   |   51 
++---
 tests/ntfsv/tet_longDnObject_notification.c |  188 
+++
 2 files changed, 196 insertions(+), 43 deletions(-)


Testing Commands:
-
 Run test cases in suite #36


Testing, Expected Results:
--
 All tests PASS


Conditions of Submission:
-
 Get ack from peer reviewers


Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  n  n
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] ntfsv: refactor logging long dn notification [#1585]

2016-08-11 Thread Vu Minh Nguyen
 osaf/services/saf/ntfsv/ntfs/NtfLogger.cc   |   51 +-
 tests/ntfsv/tet_longDnObject_notification.c |  188 +++-
 2 files changed, 196 insertions(+), 43 deletions(-)


Remove the part of code that truncates the long DN.
And update the long DN test suite (#36) to make sure full record logged.

diff --git a/osaf/services/saf/ntfsv/ntfs/NtfLogger.cc 
b/osaf/services/saf/ntfsv/ntfs/NtfLogger.cc
--- a/osaf/services/saf/ntfsv/ntfs/NtfLogger.cc
+++ b/osaf/services/saf/ntfsv/ntfs/NtfLogger.cc
@@ -21,6 +21,7 @@
  */
 #include 
 
+#include "osaf_utility.h"
 #include "saAis.h"
 #include "saLog.h"
 #include "NtfAdmin.hh"
@@ -232,48 +233,22 @@ SaAisErrorT NtfLogger::logNotification(N
notif->getNotificationId(),
SA_LOG_RECORD_WRITE_ACK,
&logRecord);
-if (SA_AIS_OK != errorCode) {
-  LOG_NO("Failed to log an alarm or security alarm notification (%d)", 
errorCode);
-  if (errorCode == SA_AIS_ERR_LIBRARY || errorCode == 
SA_AIS_ERR_BAD_HANDLE) {
-LOG_ER("Fatal error SA_AIS_ERR_LIBRARY or SA_AIS_ERR_BAD_HANDLE; 
exiting (%d)...", errorCode);
-exit(EXIT_FAILURE);
-  } else if (errorCode == SA_AIS_ERR_INVALID_PARAM) {
-/* Retry to log truncated notificationObject/notifyingObject because
- * LOG Service has not supported long dn in Opensaf 4.5
- */
-char short_dn[SA_MAX_UNEXTENDED_NAME_LENGTH];
-memset(&short_dn, 0, SA_MAX_UNEXTENDED_NAME_LENGTH);
-SaNameT shortdn_notificationObject, shortdn_notifyingObject;
-if (osaf_is_an_extended_name(ntfHeader->notificationObject)) {
-  strncpy(short_dn, 
osaf_extended_name_borrow(ntfHeader->notificationObject)
-  , SA_MAX_UNEXTENDED_NAME_LENGTH - 1);
-  osaf_extended_name_lend(short_dn, &shortdn_notificationObject);
-  logRecord.logHeader.ntfHdr.notificationObject = 
&shortdn_notificationObject;
-}
-if (osaf_is_an_extended_name(ntfHeader->notifyingObject)) {
-  strncpy(short_dn, 
osaf_extended_name_borrow(ntfHeader->notifyingObject)
-  , SA_MAX_UNEXTENDED_NAME_LENGTH - 1);
-  osaf_extended_name_lend(short_dn, &shortdn_notifyingObject);
-  logRecord.logHeader.ntfHdr.notifyingObject = 
&shortdn_notifyingObject;
-}
-if (short_dn[0] != '\0') {
-  LOG_NO("Retry to log the truncated 
notificationObject/notifyingObject");
-  if ((errorCode = saLogWriteLogAsync(alarmStreamHandle,
-  notif->getNotificationId(),
-  SA_LOG_RECORD_WRITE_ACK,
-  &logRecord)) != SA_AIS_OK) {
-LOG_ER("Failed to log the truncated 
notificationObject/notifyingObject (%d)"
-   , errorCode);
-  }
-}
-  }
-  goto end;
+switch (errorCode) {
+case SA_AIS_OK:
+   break;
+
+/* LOGsv is busy. Put the notification to queue and re-send next time */
+case SA_AIS_ERR_TRY_AGAIN:
+case SA_AIS_ERR_TIMEOUT:
+   TRACE("Failed to log notification (ret: %d). Try next time.", 
errorCode);
+   break;
+
+default:
+   osaf_abort(errorCode);
 }
   }
 
-end:
   TRACE_LEAVE();
-
   return errorCode;
 }
 
diff --git a/tests/ntfsv/tet_longDnObject_notification.c 
b/tests/ntfsv/tet_longDnObject_notification.c
--- a/tests/ntfsv/tet_longDnObject_notification.c
+++ b/tests/ntfsv/tet_longDnObject_notification.c
@@ -19,6 +19,7 @@
  */
 #include 
 #include 
+#include 
 #include "tet_ntf.h"
 #include "tet_ntf_common.h"
 //#include "util.h"
@@ -57,6 +58,166 @@ static SaNtfSecurityAlarmNotificationT m
 extern void saAisNameLend(SaConstStringT value, SaNameT* name);
 extern SaConstStringT saAisNameBorrow(const SaNameT* name);
 
+//>
+// For backup and restore IMM attribute values.
+//<
+
+#define MAX_DATA 256
+typedef struct {
+   char name[MAX_DATA];
+   char val[MAX_DATA];
+   int val_is_num;
+} attrinfo_t;
+
+typedef struct {
+   attrinfo_t *attr;
+   size_t size;
+} attrlist_t;
+
+typedef struct {
+   attrlist_t *alist;
+   char dn[MAX_DATA];
+} imminfo_t;
+
+static void getVal(imminfo_t *info)
+{
+   FILE *fp = NULL;
+   attrinfo_t *tmp = NULL;
+   char attrValue[MAX_DATA] = {0};
+   char command[MAX_DATA] = {0};
+   size_t s = info->alist->size;
+
+   tmp = info->alist->attr;
+   while (s) {
+   sprintf(command, "immlist -a %s %s "
+   "| awk -F \"=\" '{print $2}' ", tmp->name,
+   info->dn);
+   fp = popen(command, "r");
+   while (fgets(attrValue, sizeof(attrValue) - 1, fp) != NULL) {};
+   pclose(fp);
+   strtok(attrValue, "\n");
+   strncpy(tmp->val, attrValue, MAX_DATA);
+   s--;
+

Re: [devel] [PATCH 1 of 5] amfd: replace SaNameT with string in include dir [#1642]

2016-08-11 Thread Long Nguyen
Hi Praveen,

Thanks for your suggestion.
In the situation you described below, you add a csi dynamically (long 
DN) to an application (not support long DN).
So, we only need to truncate the csi name. This will help the 
application not crashed.
In my opinion, we only need to truncate in case of CSISet or CSIRemove. 
There may be some problems with applications associated with more than 
one csi, if the applications base on csi names to do special things.
In case of protection group, when we call saAmfProtectionGroupTrack, we 
have to specify the csi_name. It is not in the case of long DN since the 
application does not support long DN.

Best regards,
Long Nguyen.

On 8/11/2016 1:29 PM, praveen malviya wrote:
> Hi,
>
> I think, as of now, approaches discussed in this mail thread can be 
> mixed for a temporary solution: Dispatch() can return SA_AIS_OK by 
> invoking the callback(s) with truncated values for any long field 
> (like comp name, csi name etc). In this way comp will have callbacks 
> and AMF will also be maintaining legal COMPCSIs. Actual values can be 
> logged. Also the the PR doc and Readme should talk how truncation will 
> be performed.
> I think, this can be done in this release.
> Other solution of rejecting the CCB itself can be postponed as of now.
>
>
> Thanks,
> Praveen
>
> On 11-Aug-16 10:03 AM, Long Nguyen wrote:
>> Hi Praveen and others,
>>
>> I have an idea marked with [Long] below.
>>
>> Best regards,
>> Long Nguyen.
>>
>> On 8/3/2016 1:45 PM, praveen malviya wrote:
>>>
>>>
>>> On 02-Aug-16 3:39 AM, minh chau wrote:
 Hi Praveen,

 One comment with [Minh] in line.

 Thanks,
 Minh

 On 01/08/16 17:22, Gary Lee wrote:
> Hi Praveen
>
> On 1/08/2016 4:29 PM, praveen malviya wrote:
>> Hi Gary, Long,
>>
>> Some comments/observations:
>> -In AMFD saAisNameBorrow() is used in logging and AMFND uses
>> osaf_extended_name_borrow().
>> For osaf_extended_name_borrow() note in osaf_extended_name.h says it
>> is intended for mainly agent libraries. But middle-ware services
>> always use core libs. At the same time saAisNameBorrow(), I 
>> think, is
>> for application.
>> any reason of using them this way and what is the recommended way?
> I think I used both styles in amfd. I think we can change saAisNameXX
> to osaf_extended_name_XX just before pushing, to make it consistent
> with the rest of the OpenSAF services.
>> -I think, one case may arrive from upgrade perspective.
>> Suppose any application (say amf_demo app) is running without
>> enabling long dn and a csi, with its RDn greater than 256, is added
>> dynamically (long dn enabled in IMM). In this case AMFD will assign
>> this csi to the running component. Component will not be able to 
>> read
>> the CSI and may crash.
>> This is related to invocation of CSI_SET callback but same will be
>> valid for PG tracking also. There may be other cases also.
>> Even truncation will not work in this case.
 [Minh] I think the agent patch that Gary submitted currently returns
 SA_AIS_ERR_NAME_TOO_LONG in saAmfDispatch() if long DN callback 
 comes to
 legacy application (unadapted long DN app). The real callback won't be
 issued but application may crash if it exit() on non-SA_AIS_OK from
 Dispatch(). I guess you have seen this with #1553? Do you think it's
 good way if amf agent drops the long DN callback and also Dispatch()
 returns OK to legacy app, and print error in syslog?
>>> Not observed in the context of #1553, but I remember about such a fix
>>> in NTF long dn changes.
>>> Returning SA_AIS_OK in Dispatch() call saves application from crash,
>>> but the problem in AMF is still different as it will maintain a
>>> COMPCSI relationship without comp being actually assigned for that.
>>>
>>> Can we think of a way where AMF will not allow this conf change by
>>> rejecting the CCB operation itself. For this AMF should know that this
>>> application supports Long dn or not. But this information needs to be
>>> carried from agent to AMFD.
>>> Before going for such a way, I think, we can ask opinion from other
>>> AMF maintainers.
>>> [Long] You have the good solution. However, it is hard to know if an
>>> application supports long DN or not at the time of CCB operration. Can
>>> we make your suggestion as an enhancement later?
>>>
>>> Thanks,
>>> Praveen
>>>
>>>
>>>
>> - While running some tests observed crashes in amfnd and amfd.
>> I will update #1642 with bt information.
> Minh will answer this bit.
>
> Thanks
> Gary
>

>>>
>>
>


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, 

[devel] [PATCH 1 of 1] imm: Do not revert isApplier and isPbe flag when timeout occurs [#1943]

2016-08-11 Thread Hung Nguyen
 osaf/libs/agents/saf/imma/imma_oi_api.c |  10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)


Do not revert isApplier and isPbe flag when timeout occurs.

diff --git a/osaf/libs/agents/saf/imma/imma_oi_api.c 
b/osaf/libs/agents/saf/imma/imma_oi_api.c
--- a/osaf/libs/agents/saf/imma/imma_oi_api.c
+++ b/osaf/libs/agents/saf/imma/imma_oi_api.c
@@ -1425,7 +1425,15 @@ SaAisErrorT saImmOiImplementerSet(SaImmO
}
}
 
-   if(rc != SA_AIS_OK && cl_node) { /* Revert any flags set 
optimistically. */
+   /* Revert any flags set optimistically.
+*
+* In case of SA_AIS_ERR_TIMEOUT, we don't revert the flag to prevent
+* the library from crashing when receiving upcalls.
+*
+* cl_node->mImplementerId is not set in case of errors, so clients
+* have to either finalize the handle or retry to set implementer.
+*/
+   if(rc != SA_AIS_OK && rc != SA_AIS_ERR_TIMEOUT && cl_node) {
cl_node->isApplier = 0x0;
cl_node->isPbe = 0x0;
}

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 0 of 1] Review Request for imm: Do not revert isApplier and isPbe flag when timeout occurs [#1943]

2016-08-11 Thread Hung Nguyen
Summary: imm: Do not revert isApplier and isPbe flag when timeout occurs [#1943]
Review request for Trac Ticket(s): 1943
Peer Reviewer(s): Zoran, Neel
Pull request to:
Affected branch(es): 4.7, 5.0, 5.1
Development branch: 5.1


Impacted area   Impact y/n

 Docsn
 Build systemn
 RPM/packaging   n
 Configuration files n
 Startup scripts n
 SAF servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-


changeset 1fe934cdf3795c62dd71b89087075c6782a7d45c
Author: Hung Nguyen 
Date:   Thu, 11 Aug 2016 14:08:29 +0700

imm: Do not revert isApplier and isPbe flag when timeout occurs [#1943]

Do not revert isApplier and isPbe flag when timeout occurs.


Complete diffstat:
--
 osaf/libs/agents/saf/imma/imma_oi_api.c |  10 +-
 1 files changed, 9 insertions(+), 1 deletions(-)


Testing Commands:
-



Testing, Expected Results:
--



Conditions of Submission:
-
Ack from reviewers.


Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  n  n
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

___ Your changes affect IPC mechanism, and you don't present any results
for in-service upgradability test.

___ Your changes affect user manual and documentation, your patch series
do not contain the patch that updates the Doxygen manual.


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel