date:20160727

Re: [devel] [PATCH 0 of 3] Review Request for lgsv: Log Service CLM integration [#1638] V1

2016-07-27 Thread Anders Widell

Hi!

Some comments:

1) Have you considered using std::map instead of adding a new instance 
of NCS_PATRICIA_TREE?
2) At least when adding completely new files (lgs_clm.cc in this case), 
could you try to keep them "clean" from cppcheck and cpplint warnings 
(i.e. make sure there are no warnings in newly added files)?
3) You have added the new file lgs_clm.cc, but there is no corresponding 
lgs_clm.h header file. Could you also add the file lgs_clm.h and put the 
public API of lgs_clm.cc in it?
4) lgs_clm.cc has only one single #include statement, which includes 
"lgs.h". But it uses many interfaces that are not declared in lgs.h. You 
should not rely on header files being indirectly included from other 
header files. lgs_clm.cc ought to include all headers that it needs, for 
example: "saClm.h" for the CLM API,  for uint32_t et.al., 
"logtrace.h" for the OpenSAF trace API,  for the exit() 
function and the EXIT_FAILURE constant,  for the pthreads API.
5) Isn't the variable name usr2_sel_obj misleading? There is another 
variable with the very similar name usr1_sel_obj, and it is a selection 
object which is used when the process receives the SIGUSR1 signal. I 
would have expected that usr2_sel_obj would correspondingly be used when 
the process receives the SIGUSR2 signal. However, it seems that instead 
it is actually used to signal an MDS up event for AMFD. I think it ought 
to be renamed to reflect this. Or maybe even get rid of this selection 
object and instead post a message in the mailbox when we get this MDS event?
6) Why is the usr2_sel_obj created only in the case the when the LOG 
service is started by NID? This only makes sense for the usr1_sel_obj 
which is used to signal AMF instantiation when the process has already 
been started by NID. To me it looks like the code currently doesn't work 
when it is not started by NID - in this case clmSelectionObject will be 
initialized to -1 and stay that way forever.
7) I suppose the whole reason for triggering CLM initalization after MDS 
up event from AMFD, using this usr2_sel_obj variable, is to solve some 
circular dependency problem. But is it at all needed when CLM 
initialization is taken care of in a separate thread? Wouldn't it work 
fine if you simply start this CLM initialization thread when you receive 
an AMF assignment (i.e. start the thread from inside the 
initialize_for_assignment() function)? Could you try it? :-)
8) In C++, please use nullptr instead of NULL and 0 (when the type is 
supposed to be a pointer). So e.g. clm_callbacks should have have 
nullptr instead if 0 in its first position, and lgs_clm_init_thread 
ought to return nullptr instead of NULL.

thanks,
Anders Widell

On 07/26/2016 10:42 AM, mahesh.va...@oracle.com wrote:
> Summary:lgsv: Log Service CLM integration [#1638] V1
> Review request for Trac Ticket(s): #1638
> Peer Reviewer(s): Vu, Lennart
> 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 0637f0bfc39b5173776b3cdca088cffd28425432
> Author:   A V Mahesh 
> Date: Tue, 26 Jul 2016 14:07:35 +0530
>
>   lga: agent Cluster Membership (CLM) integration [#1638] V1 Description:
>
>   Form CLM integration is supported from Log Service A.02.02.
>
>   At-least a A.02.02 LGA client will check CLM membership status of 
> client's
>   node. old LGA clients A.02.01 are always clm member.
>
>   This patch enhanced the log service for Unavailability of the Log 
> Service
>   API on a Non-Member Node which will fail with SA_AIS_ERR_UNAVAILABLE.
>
>   After this patch the Log Service does not provide service to processes 
> on
>   cluster nodes that are not in the cluster membership.
>
>   If the node rejoins the cluster membership, processes executing on the 
> node
>   will be able to reinitialize new library handles and use the entire set 
> of
>   Log Service APIs that operate on these new handles; however, invocation 
> of
>   APIs that operate on handles acquired by any process before the node 
> left
>   the membership will continue to fail with SA_AIS_ERR_UNAVAILABLE (or 
> with
>   the special treatment described above for asynchronous calls) with the
>   exception of saLogFinalize(), which is used to free the library handles 
> and
>   all resources associated with these handles. Hence, it is recommended 
> for
>   the processes to finalize the library

Re: [devel] [PATCH 4 of 5] imm: Added the updated OpensafImm class [#195]

2016-07-27 Thread Neelakanta Reddy

The patch 4 of 5 is not complete, as forgot to add the new_file useful 
at the time of upgrade.

Attaching the patch 4 of 5 with new_file.

Regards,
Neel.

On 2016/07/27 02:01 PM, reddy.neelaka...@oracle.com wrote:

  tests/immsv/management/test_saImmOmAccessorGet_2.c |  2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/tests/immsv/management/test_saImmOmAccessorGet_2.c 
b/tests/immsv/management/test_saImmOmAccessorGet_2.c
--- a/tests/immsv/management/test_saImmOmAccessorGet_2.c
+++ b/tests/immsv/management/test_saImmOmAccessorGet_2.c
@@ -133,7 +133,7 @@ void saImmOmAccessorGet_2_04(void)
  rc = saImmOmAccessorGet_2(accessorHandle, , 
accessorGetConfigAttrsToken, );
  /* Verify the number of config attributes */
  cnt = print_SaImmAttrValuesT_2(attributes);
-assert(cnt == 8);
+assert(cnt == 12);
  test_validate(rc, SA_AIS_OK);
  safassert(saImmOmFinalize(immOmHandle), SA_AIS_OK);
  }

--
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


diff --git a/samples/immsv/OpensafImm_Upgrade_5.1.xml 
b/samples/immsv/OpensafImm_Upgrade_5.1.xml
new file mode 100644
--- /dev/null
+++ b/samples/immsv/OpensafImm_Upgrade_5.1.xml
@@ -0,0 +1,113 @@
+
+http://www.w3.org/2001/XMLSchema-instance; 
xsi:noNamespaceSchemaLocation="SAI-AIS-IMM-XSD-A.02.13.xsd" 
xmlns:xs="http://www.w3.org/2001/XMLSchema; 
xmlns:imm="http://www.saforum.org/IMMSchema;>
+  
+SA_CONFIG
+
+  opensafImm
+  SA_NAME_T
+  SA_CONFIG
+  SA_INITIALIZED
+
+
+  maxClasses
+  SA_UINT32_T
+  SA_CONFIG
+  SA_WRITABLE
+  1000
+
+
+  maxImplementers
+  SA_UINT32_T
+  SA_CONFIG
+  SA_WRITABLE
+  3000
+
+
+  maxAdminowners
+  SA_UINT32_T
+  SA_CONFIG
+  SA_WRITABLE
+  2000
+
+
+  maxCcbs
+  SA_UINT32_T
+  SA_CONFIG
+  SA_WRITABLE
+  1
+
+
+  scAbsenceAllowed
+  SA_UINT32_T
+  SA_RUNTIME
+  SA_PERSISTENT
+  SA_CACHED
+  0
+
+
+  accessControlMode
+  SA_UINT32_T
+  SA_CONFIG
+  SA_WRITABLE
+  0
+
+
+  authorizedGroup
+  SA_STRING_T
+  SA_CONFIG
+  SA_WRITABLE
+
+
+  longDnsAllowed
+  SA_UINT32_T
+  SA_CONFIG
+  SA_WRITABLE
+  0
+
+
+  opensafImmSyncBatchSize
+  SA_UINT32_T
+  SA_CONFIG
+  SA_WRITABLE
+  65223
+
+
+  opensafImmNostdFlags
+  SA_UINT32_T
+  SA_RUNTIME
+  SA_CACHED
+  0
+
+
+  opensafImmEpoch
+  SA_UINT32_T
+  SA_RUNTIME
+  SA_PERSISTENT
+  SA_CACHED
+
+
+  opensafImmClassNames
+  SA_STRING_T
+  SA_RUNTIME
+  SA_MULTI_VALUE
+  SA_PERSISTENT
+  SA_CACHED
+
+
+  SaImmAttrImplementerName
+  SA_STRING_T
+  SA_CONFIG
+
+
+  SaImmAttrClassName
+  SA_STRING_T
+  SA_CONFIG
+  OpensafImm
+
+
+  SaImmAttrAdminOwnerName
+  SA_STRING_T
+  SA_CONFIG
+
+  
+
diff --git a/tests/immsv/management/test_saImmOmAccessorGet_2.c 
b/tests/immsv/management/test_saImmOmAccessorGet_2.c
--- a/tests/immsv/management/test_saImmOmAccessorGet_2.c
+++ b/tests/immsv/management/test_saImmOmAccessorGet_2.c
@@ -133,7 +133,7 @@ void saImmOmAccessorGet_2_04(void)
 rc = saImmOmAccessorGet_2(accessorHandle, , 
accessorGetConfigAttrsToken, );
 /* Verify the number of config attributes */
 cnt = print_SaImmAttrValuesT_2(attributes);
-assert(cnt == 8);
+assert(cnt == 12);
 test_validate(rc, SA_AIS_OK);
 safassert(saImmOmFinalize(immOmHandle), SA_AIS_OK);
 }
--
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 0 of 1] Review Request for imm: Fix memory leak in saImmOmCcbObjectRead [#1927]

2016-07-27 Thread Neelakanta Reddy

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2016/07/21 03:19 PM, Hung Nguyen wrote:
> Summary: imm: Fix memory leak in saImmOmCcbObjectRead [#1927]
> Review request for Trac Ticket(s): 1927
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 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 097ec0d098d9cf5d861addecea5c3184d3b7261d
> Author:   Hung Nguyen 
> Date: Thu, 21 Jul 2016 16:47:18 +0700
>
>   imm: Fix memory leak in saImmOmCcbObjectRead [#1927]
>
>   Fix memory leak in saImmOmCcbObjectRead.
>
>
> Complete diffstat:
> --
>   osaf/libs/agents/saf/imma/imma_om_api.c |  6 ++
>   1 files changed, 6 insertions(+), 0 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
> valgrind --leak-check=full --track-origins=yes immomtest 6 74
>
>
> 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

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

2016-07-27 Thread Vo Minh Hoang

Dear Mahesh,

Thank you very much for your provided information.
I will continue investigating this problem.

Sincerely,
Hoang

-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com] 
Sent: Wednesday, July 27, 2016 4:53 PM
To: Vo Minh Hoang ; 'Nhat Pham'
; anders.wid...@ericsson.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] cpsv: To update checkpoint user number for each
node [#1669] V3

Hi  Hoang,

I still able to reproduce the problem , some time it increments two time of
current readers ,

some time it is getting  decremented to less then zero ( variable are set
(0xfff6) )

Unfortunately I don't have any specific steps order , but this issue occurs
in cluster setup with  1new controller & 1 old controller  and  2 old
payloads

when tow  application opened & holded  on old payloads ( don't exist) , and
try to do fail-overs of controllers and then exit the applications on both
payloads,

you will end up with error.

I broad , I suggest you look at the new messages that are getting introduced
in this patch are prevented with version check


===

PL-3:~ # immlist safCkpt=checkpoint_test77
Name   Type Value(s)

safCkptSA_STRING_T 
safCkpt=checkpoint_test77
saCkptCheckpointUsedSize   SA_UINT64_T 110 (0x6e)
saCkptCheckpointSize   SA_UINT64_T 2097152 
(0x20)
saCkptCheckpointRetDurationSA_TIME_T 
9223372036854775807 (0x7fff, Sat Apr 12 05:17:16 2262)
saCkptCheckpointNumWriters SA_UINT32_T 
4294967286 (0xfff6)
saCkptCheckpointNumSectionsSA_UINT32_T  1 (0x1)
saCkptCheckpointNumReplicasSA_UINT32_T  2 (0x2)
saCkptCheckpointNumReaders SA_UINT32_T 
4294967286 (0xfff6)
saCkptCheckpointNumOpeners SA_UINT32_T  0 (0x0)
saCkptCheckpointNumCorruptSections SA_UINT32_T  0 (0x0)
saCkptCheckpointMaxSectionsSA_UINT32_T  1 (0x1)
saCkptCheckpointMaxSectionSize SA_UINT64_T 2097152 
(0x20)
saCkptCheckpointMaxSectionIdSize   SA_UINT64_T 256 (0x100)
*saCkptCheckpointCreationTimestamp  SA_TIME_T 
14696097540 (0x14651a48f19e8400, Wed Jul 27 14:25:54 2016)*
saCkptCheckpointCreationFlags  SA_UINT32_T  2 (0x2)
SaImmAttrImplementerName   SA_STRING_T 
safCheckPointService
SaImmAttrClassName SA_STRING_T 
SaCkptCheckpoint
SaImmAttrAdminOwnerNameSA_STRING_T 



SC-2:~ # immlist safCkpt=checkpoint_test77
Name   Type Value(s)

safCkptSA_STRING_T 
safCkpt=checkpoint_test77
saCkptCheckpointUsedSize   SA_UINT64_T 110 (0x6e)
saCkptCheckpointSize   SA_UINT64_T 2097152 
(0x20)
saCkptCheckpointRetDurationSA_TIME_T 
9223372036854775807 (0x7fff, Sat Apr 12 05:17:16 2262)
saCkptCheckpointNumWriters SA_UINT32_T  20 (0x14)
saCkptCheckpointNumSectionsSA_UINT32_T  1 (0x1)
saCkptCheckpointNumReplicasSA_UINT32_T  2 (0x2)
saCkptCheckpointNumReaders SA_UINT32_T  20 (0x14)
saCkptCheckpointNumOpeners SA_UINT32_T  20 (0x14)
saCkptCheckpointNumCorruptSections SA_UINT32_T  0 (0x0)
saCkptCheckpointMaxSectionsSA_UINT32_T  1 (0x1)
saCkptCheckpointMaxSectionSize SA_UINT64_T 2097152 
(0x20)
saCkptCheckpointMaxSectionIdSize   SA_UINT64_T 256 (0x100)
*saCkptCheckpointCreationTimestamp  SA_TIME_T 
14696106140 (0x14651b112d9d1c00, Wed Jul 27 14:40:14 2016)*
saCkptCheckpointCreationFlags  SA_UINT32_T  2 (0x2)
SaImmAttrImplementerName   SA_STRING_T 
safCheckPointService
SaImmAttrClassName SA_STRING_T 
SaCkptCheckpoint
SaImmAttrAdminOwnerNameSA_STRING_T 


===

-AVM

On 7/26/2016 8:41 AM, Vo Minh Hoang wrote:
> Dear Mahesh,
>
> Thank you very much for your checking.
>
> Unfortunately, I unsuccessfully reproduce this problem in our environment.
> Would you please send us the trace log of d and nd of both

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

2016-07-27 Thread A V Mahesh

Hi  Hoang,

I still able to reproduce the problem , some time it increments two time 
of current readers ,

some time it is getting  decremented to less then zero ( variable are 
set (0xfff6) )

Unfortunately I don't have any specific steps order , but this issue 
occurs in cluster setup with  1new controller & 1 old controller  and  2 
old payloads

when tow  application opened & holded  on old payloads ( don't exist) , 
and try to do fail-overs of controllers and then exit the applications  
on both payloads,

you will end up with error.

I broad , I suggest you look at the new messages that are getting 
introduced  in this patch are prevented with version check

===

PL-3:~ # immlist safCkpt=checkpoint_test77
Name   Type Value(s)

safCkptSA_STRING_T 
safCkpt=checkpoint_test77
saCkptCheckpointUsedSize   SA_UINT64_T 110 (0x6e)
saCkptCheckpointSize   SA_UINT64_T 2097152 
(0x20)
saCkptCheckpointRetDurationSA_TIME_T 
9223372036854775807 (0x7fff, Sat Apr 12 05:17:16 2262)
saCkptCheckpointNumWriters SA_UINT32_T 
4294967286 (0xfff6)
saCkptCheckpointNumSectionsSA_UINT32_T  1 (0x1)
saCkptCheckpointNumReplicasSA_UINT32_T  2 (0x2)
saCkptCheckpointNumReaders SA_UINT32_T 
4294967286 (0xfff6)
saCkptCheckpointNumOpeners SA_UINT32_T  0 (0x0)
saCkptCheckpointNumCorruptSections SA_UINT32_T  0 (0x0)
saCkptCheckpointMaxSectionsSA_UINT32_T  1 (0x1)
saCkptCheckpointMaxSectionSize SA_UINT64_T 2097152 
(0x20)
saCkptCheckpointMaxSectionIdSize   SA_UINT64_T 256 (0x100)
*saCkptCheckpointCreationTimestamp  SA_TIME_T 
14696097540 (0x14651a48f19e8400, Wed Jul 27 14:25:54 2016)*
saCkptCheckpointCreationFlags  SA_UINT32_T  2 (0x2)
SaImmAttrImplementerName   SA_STRING_T 
safCheckPointService
SaImmAttrClassName SA_STRING_T 
SaCkptCheckpoint
SaImmAttrAdminOwnerNameSA_STRING_T 



SC-2:~ # immlist safCkpt=checkpoint_test77
Name   Type Value(s)

safCkptSA_STRING_T 
safCkpt=checkpoint_test77
saCkptCheckpointUsedSize   SA_UINT64_T 110 (0x6e)
saCkptCheckpointSize   SA_UINT64_T 2097152 
(0x20)
saCkptCheckpointRetDurationSA_TIME_T 
9223372036854775807 (0x7fff, Sat Apr 12 05:17:16 2262)
saCkptCheckpointNumWriters SA_UINT32_T  20 (0x14)
saCkptCheckpointNumSectionsSA_UINT32_T  1 (0x1)
saCkptCheckpointNumReplicasSA_UINT32_T  2 (0x2)
saCkptCheckpointNumReaders SA_UINT32_T  20 (0x14)
saCkptCheckpointNumOpeners SA_UINT32_T  20 (0x14)
saCkptCheckpointNumCorruptSections SA_UINT32_T  0 (0x0)
saCkptCheckpointMaxSectionsSA_UINT32_T  1 (0x1)
saCkptCheckpointMaxSectionSize SA_UINT64_T 2097152 
(0x20)
saCkptCheckpointMaxSectionIdSize   SA_UINT64_T 256 (0x100)
*saCkptCheckpointCreationTimestamp  SA_TIME_T 
14696106140 (0x14651b112d9d1c00, Wed Jul 27 14:40:14 2016)*
saCkptCheckpointCreationFlags  SA_UINT32_T  2 (0x2)
SaImmAttrImplementerName   SA_STRING_T 
safCheckPointService
SaImmAttrClassName SA_STRING_T 
SaCkptCheckpoint
SaImmAttrAdminOwnerNameSA_STRING_T 

===

-AVM

On 7/26/2016 8:41 AM, Vo Minh Hoang wrote:
> Dear Mahesh,
>
> Thank you very much for your checking.
>
> Unfortunately, I unsuccessfully reproduce this problem in our environment.
> Would you please send us the trace log of d and nd of both SC-1 and SC-2
> when error occur for investigating.
>
> For reference, here is my reproduce steps:
> 1. prepare SC-1 with patch, SC-2 without patch
> 2. create checkpoint in SC-1
> 3. open checkpoint in SC-2
> 4. immlist to get checkpoint information
> 5. unlink and close checkpoint in SC-1
> 6. immlist again to confirm its deletion
> 7. create checkpoint again in SC-1
> 8. list all replica in sharemem, there is a different here, in you error
> log, why sharemem is different

[devel] [PATCH 5 of 5] imm: updated README [#195]

2016-07-27 Thread reddy . neelakanta

 osaf/services/saf/immsv/README |  43 ++
 1 files changed, 43 insertions(+), 0 deletions(-)


diff --git a/osaf/services/saf/immsv/README b/osaf/services/saf/immsv/README
--- a/osaf/services/saf/immsv/README
+++ b/osaf/services/saf/immsv/README
@@ -2846,6 +2846,49 @@ been bound on the local node by the same
 Applier name continues to be shared between nodes, while object and class
 applier bindings are kept on the originating node.
 
+IMM Hardcoded limits as config parameters (5.1)
+===
+http://sourceforge.net/p/opensaf/tickets/195/
+
+The enhancemnets makes IMM limts configurable. The limits like maxClasses,
+maxImplementers, maxAdminowners and maxCcbs are allowed as configurable.
+The limits are added as attributes to the imm object 
+"opensafImm=opensafImm,safApp=safImmService".
+
+The default values configured for these attributes are :
+
+IMMSV_MAX_CLASSES 1000
+IMMSV_MAX_IMPLEMENTERS 3000
+IMMSV_MAX_ADMINOWNERS 2000
+IMMSV_MAX_CCBS 1
+
+The user can not configure the values less than the default values.
+
+Notes on upgrading from OpenSAF 5.0 to OpenSAF 5.1
+
+OpenSAF5.1 makes the IMM attributes as configurable (#195).
+During a rolling upgrade from an earlier OpenSAF release to the 5.1 
+release there will be nodes executing the older release concurrently
+with nodes executing OpenSAF 5.0. Nodes executing the earlier release will not
+recognize the new attributes introduced in imm config object from nodes 
executing 5.0.
+
+Because of this upgrade issue, the new attribute flag added in OpenSAF 5.1 is
+not allowed unless a flag is toggled on in the opensafImmNostdFlags runtime
+attribute in the object:
+
+   opensafImm=opensafImm,safApp=safImmService.
+
+The following shell command must be used once all nodes are upgraded :
+
+immadm -o 1 -p opensafImmNostdFlags:SA_UINT32_T:256 \
+   opensafImm=opensafImm,safApp=safImmService
+
+This will set bit 9 of the 'opensafImmNostdFlags' runtime attribute inside the 
immsv.
+Operation-id '1' invoked on the object:
+
+ 'opensafImm=opensafImm,safApp=safImmService'
+
+
 
 
 DEPENDENCIES

--
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 4 of 5] imm: Added the updated OpensafImm class [#195]

2016-07-27 Thread reddy . neelakanta

 tests/immsv/management/test_saImmOmAccessorGet_2.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/tests/immsv/management/test_saImmOmAccessorGet_2.c 
b/tests/immsv/management/test_saImmOmAccessorGet_2.c
--- a/tests/immsv/management/test_saImmOmAccessorGet_2.c
+++ b/tests/immsv/management/test_saImmOmAccessorGet_2.c
@@ -133,7 +133,7 @@ void saImmOmAccessorGet_2_04(void)
 rc = saImmOmAccessorGet_2(accessorHandle, , 
accessorGetConfigAttrsToken, );
 /* Verify the number of config attributes */
 cnt = print_SaImmAttrValuesT_2(attributes);
-assert(cnt == 8);
+assert(cnt == 12);
 test_validate(rc, SA_AIS_OK);
 safassert(saImmOmFinalize(immOmHandle), SA_AIS_OK);
 }

--
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 5] Review Request for imm:Hardcoded limits are made into config parameters [#195]

2016-07-27 Thread reddy . neelakanta

Summary: Hardcoded limits are added as config parameters [#195]
Review request for Trac Ticket(s):195 
Peer Reviewer(s): Zoran, Hung
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 servicesy
 Core libraries  n
 Samples n
 Tests   n
 Other   n


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

changeset bd980ca7528061b3b8dac255d15b808871178526
Author: Neelakanta Reddy
Date:   Wed, 27 Jul 2016 13:48:35 +0530

imm: Remove the IMM limits checking in encoding and decoding [#195]

changeset f389fb5fc59a506fb4342ccd44f333c3b6296e8b
Author: Neelakanta Reddy
Date:   Wed, 27 Jul 2016 13:49:25 +0530

imm: Added new attributes to imm config class [#195]

changeset 157b4ec00ae677a693985353f6916195b2cfbcba
Author: Neelakanta Reddy
Date:   Wed, 27 Jul 2016 13:51:21 +0530

imm: Checking of Imm limits [#195]

changeset e95dcbb8b133eab87d7fc98346a94b29f01a8245
Author: Neelakanta Reddy
Date:   Wed, 27 Jul 2016 13:53:20 +0530

imm: Added the updated OpensafImm class [#195]

changeset 1059ddcaa88c7af100ab7f715894bda882802bd9
Author: Neelakanta Reddy
Date:   Wed, 27 Jul 2016 13:53:50 +0530

imm: updated README [#195]


Complete diffstat:
--
 osaf/libs/common/immsv/immsv_evt.c |   69 
---
 osaf/libs/common/immsv/include/immsv_api.h |9 
 osaf/services/saf/immsv/README |   43 +++
 osaf/services/saf/immsv/immloadd/imm_loader.cc |   28 +++-
 osaf/services/saf/immsv/immnd/ImmModel.cc  |  322 
++-
 osaf/services/saf/immsv/immnd/ImmModel.hh  |5 +-
 tests/immsv/management/test_saImmOmAccessorGet_2.c |2 +-
 7 files changed, 412 insertions(+), 66 deletions(-)


Testing Commands:
-
Test the maximum limits for each attribute.
Modify the attributes to a new value and test
Test while upgrading the node from 5.0 to default

Testing, Expected Results:
--
ERR_NO_RESOURCE or ERR_BAD_OPERATION is returned based on 
the verification against the results.

Conditions of Submission:
-
Ack from reviewers

Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  y  y
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

[devel] [PATCH 1 of 5] imm: Remove the IMM limits checking in encoding and decoding [#195]

2016-07-27 Thread reddy . neelakanta

 osaf/libs/common/immsv/immsv_evt.c |  69 +++--
 osaf/libs/common/immsv/include/immsv_api.h |   9 +++
 2 files changed, 18 insertions(+), 60 deletions(-)


diff --git a/osaf/libs/common/immsv/immsv_evt.c 
b/osaf/libs/common/immsv/immsv_evt.c
--- a/osaf/libs/common/immsv/immsv_evt.c
+++ b/osaf/libs/common/immsv/immsv_evt.c
@@ -30,11 +30,6 @@
 #include "osaf_extended_name.h"
 #include "saAis.h"
 
-#define IMMSV_MAX_CLASSES 1000
-#define IMMSV_MAX_IMPLEMENTERS 3000
-#define IMMSV_MAX_ADMINOWNERS 2000
-#define IMMSV_MAX_CCBS 1
-
 #define IMMSV_RSRV_SPACE_ASSERT(P,B,S) 
P=ncs_enc_reserve_space(B,S);osafassert(P)
 #define IMMSV_FLTN_SPACE_ASSERT(P,M,B,S) 
P=ncs_dec_flatten_space(B,M,S);osafassert(P)
 
@@ -820,7 +815,6 @@ static void immsv_evt_enc_class(NCS_UBAI
 
 static uint32_t immsv_evt_dec_class(NCS_UBAID *i_ub, IMMSV_CLASS_LIST **r)
 {
-   int depth = 1;
uint8_t c8;
 
do {
@@ -850,13 +844,7 @@ static uint32_t immsv_evt_dec_class(NCS_
ncs_dec_skip_space(i_ub, 1);
 
r = &((*r)->next);
-   ++depth;
-   } while (c8 && (depth < IMMSV_MAX_CLASSES));
-
-   if (depth >= IMMSV_MAX_CLASSES) {
-   LOG_ER("TOO MANY classes line: %u", __LINE__);
-   return NCSCC_RC_OUT_OF_MEM;
-   }
+   } while (c8);
 
return NCSCC_RC_SUCCESS;
 }
@@ -918,7 +906,6 @@ static void immsv_evt_enc_impl(NCS_UBAID
 
 static uint32_t immsv_evt_dec_impl(NCS_UBAID *i_ub, IMMSV_IMPL_LIST **q)
 {
-   int depth = 1;
uint8_t c8;
 
do {
@@ -950,13 +937,7 @@ static uint32_t immsv_evt_dec_impl(NCS_U
ncs_dec_skip_space(i_ub, 1);
 
q = &((*q)->next);
-   ++depth;
-   } while (c8 && (depth < IMMSV_MAX_IMPLEMENTERS));
-
-   if (depth >= IMMSV_MAX_IMPLEMENTERS) {
-   LOG_ER("TOO MANY implementers line:%u", __LINE__);
-   return NCSCC_RC_OUT_OF_MEM;
-   }
+   } while (c8);
 
return NCSCC_RC_SUCCESS;
 }
@@ -1015,7 +996,6 @@ static uint32_t immsv_evt_enc_admo(NCS_U
 
 static uint32_t immsv_evt_dec_admo(NCS_UBAID *i_ub, IMMSV_ADMO_LIST **p)
 {
-   int depth = 1;
uint8_t c8;
 
do {
@@ -1052,13 +1032,7 @@ static uint32_t immsv_evt_dec_admo(NCS_U
ncs_dec_skip_space(i_ub, 1);
 
p = &((*p)->next);
-   ++depth;
-   } while (c8 && (depth < IMMSV_MAX_ADMINOWNERS));
-
-   if (depth >= IMMSV_MAX_ADMINOWNERS) {
-   LOG_ER("TOO MANY Admin Owners");
-   return NCSCC_RC_OUT_OF_MEM;
-   }
+   } while (c8 );
 
return NCSCC_RC_SUCCESS;
 }
@@ -1791,61 +1765,38 @@ static uint32_t immsv_evt_enc_sublevels(
return immsv_evt_enc_name_list(o_ub, 
i_evt->info.immnd.info.admReq.objectNames);
} else if ((i_evt->info.immnd.type == 
IMMND_EVT_ND2ND_SYNC_FINALIZE) ||
(i_evt->info.immnd.type == 
IMMND_EVT_ND2ND_SYNC_FINALIZE_2)) {
-   int depth = 0;
uint8_t *p8;
 
IMMSV_ADMO_LIST *p = 
i_evt->info.immnd.info.finSync.adminOwners;
-   while (p && (depth < IMMSV_MAX_ADMINOWNERS)) {
+   while (p ) {
if (immsv_evt_enc_admo(o_ub, p) != 
NCSCC_RC_SUCCESS) {
return NCSCC_RC_OUT_OF_MEM;
}
p = p->next;
-   ++depth;
}
 
-   if (depth >= IMMSV_MAX_ADMINOWNERS) {
-   LOG_ER("TOO MANY admin owners line:%u", 
__LINE__);
-   return NCSCC_RC_OUT_OF_MEM;
-   }
-
-   depth = 0;
IMMSV_IMPL_LIST *q = 
i_evt->info.immnd.info.finSync.implementers;
 
-   while (q && (depth < IMMSV_MAX_IMPLEMENTERS)) {
+   while (q ) {
immsv_evt_enc_impl(o_ub, q);
q = q->next;
-   ++depth;
}
 
-   if (depth >= IMMSV_MAX_IMPLEMENTERS) {
-   LOG_ER("TOO MANY implementers line:%u", 
__LINE__);
-   return NCSCC_RC_OUT_OF_MEM;
-   }
-
-   depth = 0;
IMMSV_CLASS_LIST *r = 
i_evt->info.immnd.info.finSync.classes;
-   while (r && (depth < IMMSV_MAX_CLASSES)) {
+   while (r ) {
immsv_evt_enc_class(o_ub, r);
r = r->next;
-   ++depth;
-   }
-
-   if (depth >= IMMSV_MAX_CLASSES) {
-   LOG_ER("TOO MANY

[devel] [PATCH 2 of 5] imm: Added new attributes to imm config class [#195]

2016-07-27 Thread reddy . neelakanta

 osaf/services/saf/immsv/immloadd/imm_loader.cc |  28 -
 1 files changed, 26 insertions(+), 2 deletions(-)


diff --git a/osaf/services/saf/immsv/immloadd/imm_loader.cc 
b/osaf/services/saf/immsv/immloadd/imm_loader.cc
--- a/osaf/services/saf/immsv/immloadd/imm_loader.cc
+++ b/osaf/services/saf/immsv/immloadd/imm_loader.cc
@@ -293,12 +293,16 @@ void opensafClassCreate(SaImmHandleT imm
 {
 SaAisErrorT err = SA_AIS_OK;
 int retries=0;
-SaImmAttrDefinitionT_2 d1, d2, d3, d4, d5, d6, d7, d8, d9;
+SaImmAttrDefinitionT_2 d1, d2, d3, d4, d5, d6, d7, d8, d9, d10, d11, d12, 
d13;
 SaUint32T nost_flags_default = 0;
 SaUint32T batch_size_default = IMMSV_DEFAULT_MAX_SYNC_BATCH_SIZE;
 SaUint32T extended_names_enabled_default = 0;
 SaUint32T access_control_mode_default = IMM_ACCESS_CONTROL_MODE;
 SaUint32T absent_scs_allowed_default = 0;
+SaUint32T max_classes_default = 1000;
+SaUint32T max_implementers_default = 3000;
+SaUint32T max_adminOwners_default = 2000;
+SaUint32T max_ccbs_default = 1;
 
 d1.attrName = (char *) OPENSAF_IMM_ATTR_RDN;
 d1.attrValueType = SA_IMM_ATTR_SANAMET;
@@ -346,8 +350,28 @@ void opensafClassCreate(SaImmHandleT imm
 d9.attrFlags = SA_IMM_ATTR_RUNTIME | SA_IMM_ATTR_CACHED | 
SA_IMM_ATTR_PERSISTENT;
 d9.attrDefaultValue = _scs_allowed_default;
 
+d10.attrName = (char *) OPENSAF_IMMSV_MAX_CLASSES;
+d10.attrValueType = SA_IMM_ATTR_SAUINT32T;
+d10.attrFlags = SA_IMM_ATTR_CONFIG | SA_IMM_ATTR_WRITABLE;
+d10.attrDefaultValue = _classes_default;
+
+d11.attrName = (char *) OPENSAF_IMMSV_MAX_IMPLEMENTERS;
+d11.attrValueType = SA_IMM_ATTR_SAUINT32T;
+d11.attrFlags = SA_IMM_ATTR_CONFIG | SA_IMM_ATTR_WRITABLE;
+d11.attrDefaultValue = _implementers_default;
+
+d12.attrName = (char *) OPENSAF_IMMSV_MAX_ADMINOWNERS;
+d12.attrValueType = SA_IMM_ATTR_SAUINT32T;
+d12.attrFlags = SA_IMM_ATTR_CONFIG | SA_IMM_ATTR_WRITABLE;
+d12.attrDefaultValue = _adminOwners_default;
+
+d13.attrName = (char *) OPENSAF_IMMSV_MAX_CCBS;
+d13.attrValueType = SA_IMM_ATTR_SAUINT32T;
+d13.attrFlags = SA_IMM_ATTR_CONFIG | SA_IMM_ATTR_WRITABLE;
+d13.attrDefaultValue = _ccbs_default;
+
 const SaImmAttrDefinitionT_2* attrDefs[] =
-   {, , , , , , , , , 0};
+   {, , , , , , , , , , , , 
, 0};
 
 
 do {/* Create the class */

--
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 AMFD: Initialize CLM, NTF handle in thread [#1828] V2

2016-07-27 Thread Minh Hon Chau

Summary: AMFD: Initialize CLM, NTF handle in thread [#1828] V2
Review request for Trac Ticket(s): 1828
Peer Reviewer(s): AMF maintainers
Pull request to: Gary
Affected branch(es): 5.0, 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):
-
 In this V2, amfd does CLM/NTF init when amfd get active/standby role

changeset 5ae93844c6a37b4546468635a92d3c70d85aec82
Author: Minh Hon Chau 
Date:   Wed, 27 Jul 2016 18:00:25 +1000

AMFD: Initialize CLM, NTF handle in thread [#1828] V2

In new controller reallocation scenario with roaming sc feature, if 
immnd
dies in the node becoming active, the circular dependencies among 
Opensaf
services appear, which leads eventually to a reboot.

The dependencies are: .clmd can not use IMM services since immnd dies 
.immnd
needs restarted by amfnd .amfnd is hanging since amfnd is calling CLM
services .amfd is also hanging since amfd is calling CLM and NTF 
services
.ntfd is hanging due to logd's dependencies on IMM

The problem could be solved if: . amfd initializes NTF, CLM handle in 
thread
in initialization phase . amfnd initializes CLM in thread if amfnd 
receives
clm bad handle

Since amfnd has already initialized CLM in thread up on receiving clm 
bad
handle. This patch does initialze CLM, NTF in thread at amfd side. Also,
threading initialization in this patch can be refactored later by 
utilizing
the support of #1609


Complete diffstat:
--
 osaf/services/saf/amf/amfd/clm.cc|  103 
---
 osaf/services/saf/amf/amfd/include/cb.h  |7 ++-
 osaf/services/saf/amf/amfd/include/clm.h |6 ++-
 osaf/services/saf/amf/amfd/include/ntf.h |3 +
 osaf/services/saf/amf/amfd/main.cc   |   17 +++-
 osaf/services/saf/amf/amfd/ntf.cc|   85 
++
 osaf/services/saf/amf/amfd/role.cc   |   24 ++-
 7 files changed, 205 insertions(+), 40 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  y  y
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

[devel] [PATCH 1 of 1] AMFD: Initialize CLM, NTF handle in thread [#1828] V2

2016-07-27 Thread Minh Hon Chau

 osaf/services/saf/amf/amfd/clm.cc|  103 ++
 osaf/services/saf/amf/amfd/include/cb.h  |7 +-
 osaf/services/saf/amf/amfd/include/clm.h |6 +-
 osaf/services/saf/amf/amfd/include/ntf.h |3 +
 osaf/services/saf/amf/amfd/main.cc   |   17 +---
 osaf/services/saf/amf/amfd/ntf.cc|   85 +
 osaf/services/saf/amf/amfd/role.cc   |   24 +++---
 7 files changed, 205 insertions(+), 40 deletions(-)


In new controller reallocation scenario with roaming sc feature, if immnd
dies in the node becoming active, the circular dependencies among Opensaf
services appear, which leads eventually to a reboot.

The dependencies are:
.clmd can not use IMM services since immnd dies
.immnd needs restarted by amfnd
.amfnd is hanging since amfnd is calling CLM services
.amfd is also hanging since amfd is calling CLM and NTF services
.ntfd is hanging due to logd's dependencies on IMM

The problem could be solved if:
. amfd initializes NTF, CLM handle in thread in initialization phase
. amfnd initializes CLM in thread if amfnd receives clm bad handle

Since amfnd has already initialized CLM in thread up on receiving clm bad
handle. This patch does initialze CLM, NTF in thread at amfd side. Also,
threading initialization in this patch can be refactored later by utilizing
the support of #1609

diff --git a/osaf/services/saf/amf/amfd/clm.cc 
b/osaf/services/saf/amf/amfd/clm.cc
--- a/osaf/services/saf/amf/amfd/clm.cc
+++ b/osaf/services/saf/amf/amfd/clm.cc
@@ -386,14 +386,26 @@ static const SaClmCallbacksT_4 clm_callb
/*.saClmClusterTrackCallback =*/ clm_track_cb
 };
 
-SaAisErrorT avd_clm_init(void)
+SaAisErrorT avd_clm_init(AVD_CL_CB* cb)
 {
-SaAisErrorT error = SA_AIS_OK;
+   SaAisErrorT error = SA_AIS_OK;
+   SaClmHandleT clm_handle = 0;
+   SaSelectionObjectT sel_obj = 0;
 
+   cb->clmHandle = 0;
+   cb->clm_sel_obj = 0;
TRACE_ENTER();
+   /*
+* TODO: This CLM initialization thread can be re-factored
+* after having osaf dedicated thread, so that all APIs calls
+* to external service can be automatically retried with result
+* code (TRY_AGAIN, TIMEOUT, UNAVAILABLE), or reinitialized within
+* BAD_HANDLE. Also, duplicated codes in initialization thread
+* will be moved to osaf dedicated thread
+*/
for (;;) {
SaVersionT Version = { 'B', 4, 1 };
-   error = saClmInitialize_4(_cb->clmHandle, _callbacks, 
);
+   error = saClmInitialize_4(_handle, _callbacks, 
);
if (error == SA_AIS_ERR_TRY_AGAIN ||
error == SA_AIS_ERR_TIMEOUT ||
 error == SA_AIS_ERR_UNAVAILABLE) {
@@ -404,15 +416,21 @@ SaAisErrorT avd_clm_init(void)
osaf_nanosleep();
continue;
}
-   if (error == SA_AIS_OK) break;
-   LOG_ER("Failed to Initialize with CLM: %u", error);
+   if (error == SA_AIS_OK) {
+   break;
+   }else {
+   LOG_ER("Failed to Initialize with CLM: %u", error);
+   goto done;
+   }
+   }
+   cb->clmHandle = clm_handle;
+   error = saClmSelectionObjectGet(cb->clmHandle, _obj);
+   if (error != SA_AIS_OK) {
+   LOG_ER("Failed to get selection object from CLM %u", error);
+   cb->clmHandle = 0;
goto done;
}
-   error = saClmSelectionObjectGet(avd_cb->clmHandle, 
_cb->clm_sel_obj);
-   if (SA_AIS_OK != error) { 
-   LOG_ER("Failed to get selection object from CLM %u", error);
-   goto done;
-   }
+   cb->clm_sel_obj = sel_obj;
 
TRACE("Successfully initialized CLM");
 
@@ -428,10 +446,15 @@ SaAisErrorT avd_clm_track_start(void)
 
TRACE_ENTER();
error = saClmClusterTrack_4(avd_cb->clmHandle, trackFlags, nullptr);
-if (SA_AIS_OK != error)
-LOG_ER("Failed to start cluster tracking %u", error);
-
-TRACE_LEAVE();
+   if (error != SA_AIS_OK) {
+   if (error == SA_AIS_ERR_TRY_AGAIN || error == 
SA_AIS_ERR_TIMEOUT ||
+   error == SA_AIS_ERR_UNAVAILABLE) {
+   LOG_WA("Failed to start cluster tracking %u", error);
+   } else {
+   LOG_ER("Failed to start cluster tracking %u", error);
+   }
+   }
+   TRACE_LEAVE();
return error;
 }
 
@@ -468,3 +491,55 @@ void clm_node_terminate(AVD_AVND *node)
else
TRACE("Waiting for the pending SU presence state updates");
 }
+
+static void* avd_clm_init_thread(void* arg)
+{
+   TRACE_ENTER();
+   AVD_CL_CB* cb = static_cast(arg);
+   SaAisErrorT error = SA_AIS_OK;
+
+   if (avd_clm_init(cb) != SA_AIS_OK) {
+   LOG_ER("avd_clm_init

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

2016-07-27 Thread A V Mahesh

Hi Hoan,

   I tested in-service testing  on 4 node setup ( combination of old and 
new) ,  with application opened on two payloads,
   restarting controllers.

   I am trying to recollect the test case , mean while you can also give 
a try .

-AVM

On 7/26/2016 1:58 PM, A V Mahesh wrote:
> Hi Hoan,
>
> I need to refresh ,I will setup again and provide the detailed
> reproducible steps.
>
> -AVM
>
> On 7/26/2016 8:41 AM, Vo Minh Hoang wrote:
>> Dear Mahesh,
>>
>> Thank you very much for your checking.
>>
>> Unfortunately, I unsuccessfully reproduce this problem in our environment.
>> Would you please send us the trace log of d and nd of both SC-1 and SC-2
>> when error occur for investigating.
>>
>> For reference, here is my reproduce steps:
>> 1. prepare SC-1 with patch, SC-2 without patch
>> 2. create checkpoint in SC-1
>> 3. open checkpoint in SC-2
>> 4. immlist to get checkpoint information
>> 5. unlink and close checkpoint in SC-1
>> 6. immlist again to confirm its deletion
>> 7. create checkpoint again in SC-1
>> 8. list all replica in sharemem, there is a different here, in you error
>> log, why sharemem is different between SC-1 and SC-2? In my opinion sharemem
>> should be one.
>> 9. immlist to check information
>>
>> Please tell us if I miss something.
>> I am sorry for any inconvenient.
>>
>> Thank you and best regards.
>> Hoang
>>
>> -Original Message-
>> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
>> Sent: Friday, July 15, 2016 10:26 AM
>> To: Nhat Pham ; anders.wid...@ericsson.com; Nhat
>> Pham ; Hoang Vo 
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [PATCH 1 of 1] cpsv: To update checkpoint user number for each
>> node [#1669] V3
>>
>> Hi  Hoang /Nhat Pham,
>>
>>
>> The basic testing with in-service upgrade(one old  controller with
>> out patch and one new  controller with patch ) is corrupting the
>> Writers/Readers/Openers  DB,
>>
>> please verify in-service upgrade test with collocated & no-collocated ckpts
>> and address new issue and publish V4 patch.
>>
>> SC-1:/avm/opensaf_app/cpsv_applications/virtualaddr # immlist
>> safCkpt=checkpoint_test77
>> Name   Type Value(s)
>> 
>> safCkptSA_STRING_T
>> safCkpt=checkpoint_test77
>> saCkptCheckpointUsedSize   SA_UINT64_T 110 (0x6e)
>> saCkptCheckpointSize   SA_UINT64_T 2097152
>> (0x20)
>> saCkptCheckpointRetDurationSA_TIME_T
>> 9223372036854775807 (0x7fff, Sat Apr 12 05:17:16 2262)
>> saCkptCheckpointNumWriters SA_UINT32_T
>> 4294967291 (0xfffb)
>> saCkptCheckpointNumSectionsSA_UINT32_T  1 (0x1)
>> saCkptCheckpointNumReplicasSA_UINT32_T  4 (0x4)
>> saCkptCheckpointNumReaders SA_UINT32_T
>> 4294967291 (0xfffb)
>> saCkptCheckpointNumOpeners SA_UINT32_T
>> 4294967291 (0xfffb)
>> saCkptCheckpointNumCorruptSections SA_UINT32_T  0 (0x0)
>> saCkptCheckpointMaxSectionsSA_UINT32_T  1 (0x1)
>> saCkptCheckpointMaxSectionSize SA_UINT64_T 2097152
>> (0x20)
>> saCkptCheckpointMaxSectionIdSize   SA_UINT64_T 256 (0x100)
>> saCkptCheckpointCreationTimestamp  SA_TIME_T
>> 14685525530 (0x146158c4278eda00, Fri Jul 15 08:45:53 2016)
>> saCkptCheckpointCreationFlags  SA_UINT32_T  2 (0x2)
>> SaImmAttrImplementerName   SA_STRING_T
>> safCheckPointService
>> SaImmAttrClassName SA_STRING_T
>> SaCkptCheckpoint
>> SaImmAttrAdminOwnerNameSA_STRING_T 
>>
>> -AVM
>>
>>
>> On 7/13/2016 12:44 PM, A V Mahesh wrote:
>>> Hi  Hoang /Nhat Pham,
>>>
>>> I just started testing , fowling test case is failing , I may report
>>> more  as soon as I get some
>>>
>>> Test case 1 :
>>>
>>> Step 1 : saCkptCheckpointOpen  on SC-1
>>>
>>> SC-1:# ./node_A
>>> 0 saCkptCheckpointOpen  returned checkpointHandle 626bf0
>>> 1 saCkptCheckpointOpen  returned checkpointHandle 626e70
>>> 2 saCkptCheckpointOpen  returned checkpointHandle 626ff0
>>> 3 saCkptCheckpointOpen  returned checkpointHandle 627170
>>> 4 saCkptCheckpointOpen  returned checkpointHandle 6272f0
>>> saCkptCheckpointWrite Waiting to Read from Checkpoint 
>>> saCkptCheckpointWrite Press  key to continue...
>>>
>>> 1 saCkptCheckpointWrite  checkpointHandle 626bf0
>>> 2 saCkptCheckpointWrite  checkpointHandle 626bf0
>>> 3 saCkptCheckpointWrite  checkpointHandle 626bf0
>>> 4 saCkptCheckpointWrite  checkpointHandle 626bf0
>>> 222 saCkptCheckpointWrite  checkpointHandle 626bf0
>>> saCkptCheckpointRead Waiting to Read from Checkpoint 
>>>

Re: [devel] [PATCH 0 of 3] Review Request for lgsv: Log Service CLM integration [#1638] V1

Re: [devel] [PATCH 4 of 5] imm: Added the updated OpensafImm class [#195]

Re: [devel] [PATCH 0 of 1] Review Request for imm: Fix memory leak in saImmOmCcbObjectRead [#1927]

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

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

[devel] [PATCH 5 of 5] imm: updated README [#195]

[devel] [PATCH 4 of 5] imm: Added the updated OpensafImm class [#195]

[devel] [PATCH 0 of 5] Review Request for imm:Hardcoded limits are made into config parameters [#195]

[devel] [PATCH 1 of 5] imm: Remove the IMM limits checking in encoding and decoding [#195]

[devel] [PATCH 2 of 5] imm: Added new attributes to imm config class [#195]

[devel] [PATCH 0 of 1] Review Request for AMFD: Initialize CLM, NTF handle in thread [#1828] V2

[devel] [PATCH 1 of 1] AMFD: Initialize CLM, NTF handle in thread [#1828] V2

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

13 matches

Site Navigation

Mail list logo

Footer information