Re: [devel] [PATCH 1 of 1] amfnd : fix compilation problem in mbcsv.cc in amfnd module [#616]

2013-12-16 Thread Nagendra Kumar
Ack

Thanks
-Nagu

-Original Message-
From: Praveen Malviya 
Sent: 17 December 2013 11:55
To: hans.fe...@ericsson.com; Nagendra Kumar; Mathivanan Naickan Palanivelu
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 1] amfnd : fix compilation problem in mbcsv.cc in amfnd 
module [#616]

 osaf/services/saf/amf/amfnd/mbcsv.cc |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/osaf/services/saf/amf/amfnd/mbcsv.cc 
b/osaf/services/saf/amf/amfnd/mbcsv.cc
--- a/osaf/services/saf/amf/amfnd/mbcsv.cc
+++ b/osaf/services/saf/amf/amfnd/mbcsv.cc
@@ -1290,7 +1290,7 @@ uint32_t avnd_evt_avd_role_change_evh(AV
prev_ha_state = cb->avail_state_avnd;
 
/* Ignore the duplicate roles. */
-   if (prev_ha_state == info->role) {
+   if (prev_ha_state == (SaAmfHAStateT)info->role) {
return NCSCC_RC_SUCCESS;
}
 

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
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 amfnd : fix compilation problem in mbcsv.cc in amfnd module [#616]

2013-12-16 Thread praveen . malviya
Summary: amfnd : fix compilation problem in mbcsv.cc in amfnd module [#616] 
Review request for Trac Ticket(s):amf #616 
Peer Reviewer(s): Hans F., Nagendra, Mathivanan 
Pull request to: <>
Affected branch(es): Default 
Development branch: <>


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):
-
Fixing compilation problem which is observed in gcc version less than 4.5.

changeset b2bc0510a80e21c29e37bac796beb37ea814905b
Author: praveen.malv...@oracle.com
Date:   Tue, 17 Dec 2013 11:48:44 +0530

amfnd : fix compilation problem in mbcsv.cc in amfnd module [#616]


Complete diffstat:
--
 osaf/services/saf/amf/amfnd/mbcsv.cc |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Testing Commands:
-
compiled amfnd on gcc 4.1.2

Testing, Expected Results:
--
compilation successful

Conditions of Submission:
-
Ack from atleast one reviewer.

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


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfnd : fix compilation problem in mbcsv.cc in amfnd module [#616]

2013-12-16 Thread praveen . malviya
 osaf/services/saf/amf/amfnd/mbcsv.cc |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


diff --git a/osaf/services/saf/amf/amfnd/mbcsv.cc 
b/osaf/services/saf/amf/amfnd/mbcsv.cc
--- a/osaf/services/saf/amf/amfnd/mbcsv.cc
+++ b/osaf/services/saf/amf/amfnd/mbcsv.cc
@@ -1290,7 +1290,7 @@ uint32_t avnd_evt_avd_role_change_evh(AV
prev_ha_state = cb->avail_state_avnd;
 
/* Ignore the duplicate roles. */
-   if (prev_ha_state == info->role) {
+   if (prev_ha_state == (SaAmfHAStateT)info->role) {
return NCSCC_RC_SUCCESS;
}
 

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: remove UNKNOWN word from saflog [#362]

2013-12-16 Thread nagendra . k
 osaf/services/saf/amf/amfd/siass.cc |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


diff --git a/osaf/services/saf/amf/amfd/siass.cc 
b/osaf/services/saf/amf/amfd/siass.cc
--- a/osaf/services/saf/amf/amfd/siass.cc
+++ b/osaf/services/saf/amf/amfd/siass.cc
@@ -528,9 +528,9 @@ uint32_t avd_gen_su_ha_state_changed_ntf
 {
uint32_t status = NCSCC_RC_FAILURE;
 
-   TRACE_ENTER2("'%s' assigned to '%s' HA state UNKNOWN => %s", 
susi->si->name.value, 
+   TRACE_ENTER2("'%s' assigned to '%s' HA state '%s'", 
susi->si->name.value, 
susi->su->name.value, avd_ha_state[susi->state]);
-   saflog(LOG_NOTICE, amfSvcUsrName, "%s assigned to %s HA State UNKNOWN 
=> %s", 
+   saflog(LOG_NOTICE, amfSvcUsrName, "%s assigned to %s HA State '%s'", 
susi->si->name.value, susi->su->name.value, 
avd_ha_state[susi->state]);
 
/* alarm & notifications */

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
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: remove UNKNOWN word from saflog [#362]

2013-12-16 Thread nagendra . k
Summary: amfd: remove UNKNOWN word from saflog [#362]
Review request for Trac Ticket(s): #362
Peer Reviewer(s): Hans F, Hans N, Praveen 
Pull request to: 
Affected branch(es): All 
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 ace49a91fc0b197b8d3af26e490b2913357d3e5b
Author: Nagendra Kumar
Date:   Tue, 17 Dec 2013 11:39:31 +0530

amfd: remove UNKNOWN word from saflog [#362]


Complete diffstat:
--
 osaf/services/saf/amf/amfd/siass.cc |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


Testing Commands:
-
Lock appl Act SU


Testing, Expected Results:
--
The logs should look like:
NO safApp=safAmfService "safSi=AmfDemo,safApp=AmfDemo1 assigned to 
safSu=SU1,safSg=AmfDemo,safApp=AmfDemo1 HA State 'QUIESCED'


Conditions of Submission:
-
Ack from peer maintainers


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


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
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 base: use _Exit instead of exit in daemon_exit #581

2013-12-16 Thread Ramesh Betham
Changes are fine to me.

Thanks,
Ramesh.

On 12/16/2013 7:20 PM, Hans Nordebäck wrote:
> Hi Ramesh, is it ok if I push this patch today?/BR HansN
>
> -Original Message-
> From: Anders Widell
> Sent: den 10 december 2013 10:42
> To: Hans Nordebäck; Hans Feldt; ramesh.bet...@oracle.com
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 0 of 1] Review Request for base: use _Exit instead of 
> exit in daemon_exit #581
>
> Ack with comment. The ticket number is still not surrounded with square 
> brackets [#581] in the first line of the commit message.
>
> regards,
> Anders Widell
>
> 2013-12-10 10:37, Hans Nordeback skrev:
>> Summary: base: use _Exit instead of exit in daemon_exit [#581] Review
>> request for Trac Ticket(s): 581 Peer Reviewer(s): AndersW,HansF,Ramesh
>> Pull request to:
>> Affected branch(es): default(4.4)
>> 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  y
>>Samples n
>>Tests   n
>>Other   n
>>
>>
>> Comments (indicate scope for each "y" above):
>> -
>><>
>>
>> changeset 8d36c7f02507201c39204ad7afc7574bb6cdc4a0
>> Author:  Hans Nordeback 
>> Date:Tue, 10 Dec 2013 10:24:37 +0100
>>
>>  base: use _Exit instead of exit in daemon_exit #581
>>
>>  use _Exit instead of exit in daemon_exit. The change was done due to 
>> that
>>  exit() is not thread safe, see e.g. ticket #651. To make it possible to 
>> dump
>>  e.g. coverage data on termination a weak reference to __gcov_flush has 
>> been
>>  added.
>>
>>
>> Complete diffstat:
>> --
>>osaf/libs/core/common/daemon.c |  8 +++-
>>1 files changed, 7 insertions(+), 1 deletions(-)
>>
>>
>> Testing Commands:
>> -
>><>
>>
>>
>> Testing, Expected Results:
>> --
>><>
>>
>>
>> Conditions of Submission:
>> -
>><>
>>
>>
>> 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 time; confusing the
>>   the threaded patch review.
>>
>> ___ Your changes affect IPC mechanism, and you don't present any results
>>   for in-service upgradability test.
>>

Re: [devel] [PATCH 1 of 1] smfd: smfBundleCheckCmd called as part of prerequisites test [656]

2013-12-16 Thread Bertil Engelholm
Looks OK.

/Bertil

-Original Message-
From: Ingvar Bergström 
Sent: den 13 december 2013 14:08
To: Bertil Engelholm
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 1] smfd: smfBundleCheckCmd called as part of prerequisites 
test [656]

 00-README.conf   |   12 +
 osaf/services/saf/smfsv/scripts/smf-bundle-check |  139 ++
 osaf/services/saf/smfsv/smfd/SmfCampState.cc |   90 ++
 3 files changed, 88 insertions(+), 153 deletions(-)


Includes the invocation of the configured smfBundleCheckCmd command as a part 
of the prerequisites tests.
The specified command is given the DN of the SaSmfSwBundle instance to check as 
argument.

diff --git a/00-README.conf b/00-README.conf
--- a/00-README.conf
+++ b/00-README.conf
@@ -408,4 +408,16 @@ Note: If resource limits are not configu
 (running in application context) will by default have/set a non-realtime 
 priority with the scheduling policy of SCHED_OTHER.
 
+SMF bundle check command
+=
+SMF requires a command to be configured which is called to verify sw bundles 
invoked by the campaign. 
+The command is configured in the OpenSafSmfConfig attribute smfBundleCheckCmd.
+From OpenSAF 4.4 the smfBundleCheckCmd command as a part of the prerequisites 
tests.
+Interfacs: The specified command is given the DN of the SaSmfSwBundle instance 
to check as argument.
+  configuredCmd 
+   e.g. myConfiguredCommand saSmfBundle=myBundle
 
+Note: The OpenSAF default implemetation is located at 
osaf/services/saf/smfsv/scripts/smf-bundle-check.
+  Earlier default implementation of the command (which was never called 
from SMF) requires a bundle 
+  name as input parameter. 
+  From 4.4 the input parameter shall be the DN of the bundle to check.
diff --git a/osaf/services/saf/smfsv/scripts/smf-bundle-check 
b/osaf/services/saf/smfsv/scripts/smf-bundle-check
--- a/osaf/services/saf/smfsv/scripts/smf-bundle-check
+++ b/osaf/services/saf/smfsv/scripts/smf-bundle-check
@@ -15,142 +15,29 @@
 #
 # Author(s): Ericsson AB
 #
-# Default implementation of SMF bundle check
-
-# FROM THE SMF SPECIFICATION;
+# This command is called during the prerequisites test described in:
+# Service AvailabilityT Forum Application Interface Specification
+# Software Management Framework SAI-AIS-SMF-A.01.02
+# 4.1.1 Upgrade Prerequisites
+# Test 6. The desired version of the software is available in the software 
repository, and all
+# the dependencies of the required packages have been checked and are 
satisfied.
 #
-# 3.2.2.1 Repository Management
+# This file contain the default implementation of SMF bundle check.
+# The default implementation is just a placeholder for the sw bundle test call 
from SMF.
+# The tests shall be written by the user to fit the actual system hosting 
OpenSAF.
 #
-#   It is assumed that an SA Forum system is associated with a
-#   logically single storage that collects all software bundles
-#   available in the system. In the software delivery phase, software
-#   bundles are made available to the system by copying them to the
-#   software repository. The source could be a remote file server, a
-#   CD, or some other media. The Software Management Framework
-#   specification currently does not specify how software packages
-#   and, as a consequence, software bundles are imported to the
-#   repository and made available to the system.
+# Interface: The command is called with the sw budle DN as parameter.
+#configuredCommand 
 #
-#   When software bundles are delivered to the software repository,
-#   they should be verified in an implementation-specific way (for
-#   instance, by the use of package handling utilities of an operating
-#   system or by other means). This verification should include for
-#   each software bundle:
-#
-# - A check of the integrity and the origin of all software
-#   packages that make up the bundle.
-#
-# - A check that all other packages indicated in the package
-#   dependency list are available in the repository or have been
-#   delivered at the same time.
-#
-# - A check that the bundle has been properly added to the
-#   repository and can, therefore, be used as an installation
-#   source.
-#
-#   When all these operations and checks are successfully completed,
-#   the software bundle becomes available for the system and allows
-#   one to add an IMM object representing the software bundle to the
-#   information model of the software catalog.
-#
-#   If any of these operations fails, the bundle may not be added
-#   either to the repository or to the information model.
-
-# Now forget all of the above. This script checks something else...
-
-# FROM THE SMF WP Chapter III.D;
-# 1.  Administrator creating a Software Bundle object in IMM
-# 2.  IMM informing SMF that a new Software Bundle object is 

[devel] [PATCH 1 of 1] logsv test: Add more options (-e, -o) change -k and -a

2013-12-16 Thread Lennart Lund
 tests/logsv/saflogtest.c |  342 +++---
 1 files changed, 256 insertions(+), 86 deletions(-)


 - Create more than one stream in same session. With -o option
   streams stays open until any key is hit. Up to four -a can be used
   meaning that for app stream can be opened at the same time.
   If -a is used to open one stream the stream is closed before finalize.
   If -a is used to open more than one stream finalize is used without
   closing the streams first
 - Option -k is changed to default ack when write
 - Option -e is added. Means exit without closing streams or finalize
   lgs API (for testing client loss)
 - Option -o is added. Means, saflogtest will stop with streams open if
   any key is pressed it will exit depending on other options.

diff --git a/tests/logsv/saflogtest.c b/tests/logsv/saflogtest.c
--- a/tests/logsv/saflogtest.c
+++ b/tests/logsv/saflogtest.c
@@ -51,6 +51,8 @@
 #define VENDOR_ID 193
 #define DEFAULT_MAX_FILES_ROTATED 4
 
+#define MAX_NUM_STREAM 4
+
 static void logWriteLogCallbackT(SaInvocationT invocation, SaAisErrorT error);
 
 static SaLogCallbacksT logCallbacks = { 0, 0, logWriteLogCallbackT };
@@ -60,6 +62,7 @@ static char *progname = "saflogtest";
 static SaInvocationT cb_invocation;
 static SaAisErrorT cb_error;
 
+
 static SaTimeT get_current_SaTime(void)
 {
struct timeval tv;
@@ -89,17 +92,23 @@ static void usage(void)
printf("\nOPTIONS\n");
 
printf("  -h or --help   this help\n");
-   printf("  -k or --ackwait for ack after each write, 
default no wait\n");
+   printf("  -k or --ackdo not wait for ack after 
write, default wait\n");
printf("  -l or --alarm  write to alarm stream\n");
printf("  -n or --notification   write to notification 
stream\n");
printf("  -y or --system write to system stream 
(default)\n");
-   printf("  -a NAME or --application=NAME  write to application stream 
NAME\n");
+   printf("%s%s%s",
+  "  -a NAME or --application=NAME  write to application 
stream NAME\n",
+  " Can be used more than once, more than one stream can 
be opened\n",
+  " Cannot be used in combination with other streams\n");
+   printf(" Max %d application streams can be 
created\n",MAX_NUM_STREAM);
+   printf(" Example: > saflogtest -a tst1 \"tst1 msg\" -a tst2 -a tst3 
\"tst3 msg\"\n");
printf("  -b NAME or --capplication=NAME write to config application 
stream NAME\n");
printf("  -s SEV or --severity=SEV   use severity SEV, default 
INFO\n");
+   printf(" valid severity names: emerg, alert, crit, error, warn, 
notice, info\n");
printf("  -i INT or --interval=INT   write with interval INT us 
(only with --count, default 0us)\n");
printf("  -c CNT or --count=CNT  write CNT number of times, -1 
forever (with interval INT) \n");
-   printf("  valid severity names: emerg, alert, crit, error, warn, 
notice, info\n");
-   printf("  -o Open log stream and wait forever. Exit on any key\n");
+   printf("  -o Open log stream(s) and wait forever. Exit on any key\n");
+   printf("  -e Exit without closing stream(s) or finalizing after log 
records are written\n");
 }
 
 static void logWriteLogCallbackT(SaInvocationT invocation, SaAisErrorT error)
@@ -129,7 +138,7 @@ static SaAisErrorT write_log_record(SaLo
static int i = 0;
int try_agains = 0;
SaLogAckFlagsT ackflags;
-
+   
if (wait_for_ack)
ackflags = SA_LOG_RECORD_WRITE_ACK;
else
@@ -187,7 +196,7 @@ static SaAisErrorT write_log_record(SaLo
}
 
if (try_agains > 0) {
-   fprintf(stderr, "got %u SA_AIS_ERR_TRY_AGAIN, waited %u 
secs\n", try_agains, try_agains / 10);
+   fprintf(stderr, "\tgot %u SA_AIS_ERR_TRY_AGAIN, waited 
%u secs\n", try_agains, try_agains / 10);
}
}
 
@@ -221,17 +230,103 @@ static SaLogSeverityT get_severity(char 
exit(EXIT_FAILURE);
 }
 
+/**
+ * Creates a log record by filling in the log service API struct of
+ * type SaLogRecordT.
+ * Note: When the log record is written it has to be freed.
+ *   Use free_log_record() function 
+ * 
+ * @param logRecord[out]
+ * @param logHdrType[in]
+ * @param logSvcUsrName[in]
+ * @param notificationClassId[in]
+ *Can be set to NULL if Hdr-type is SA_LOG_GENERIC_HEADER
+ * @param log_message[in]
+ *Set to NULL if there is no message
+ */
+static void create_log_record(SaLogRecordT *logRecord,
+   SaLogHeaderTypeT logHdrType,
+   SaNameT *logSvcUsrName,
+   SaNtfClassIdT 
*notificationClassId,
+   

[devel] [PATCH 0 of 1] Review Request for logsv test: Add more features to saflogtest tool [#661]

2013-12-16 Thread Lennart Lund
Summary: logsv test: Add more options (-e, -o) change -k and -a
Review request for Trac Ticket(s): [#661]
Peer Reviewer(s): Mathi N
Pull request to: 
Affected branch(es): 4.4
Development branch: 


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 e8c085fb790edd7610b54c510eaa8200bcd5f8e2
Author: Lennart Lund 
Date:   Mon, 16 Dec 2013 14:48:10 +0100

logsv test: Add more options (-e, -o) change -k and -a

 - Create more than one stream in same session. With -o option streams
stays open until any key is hit. Up to four -a can be used meaning that
for app stream can be opened at the same time. If -a is used to open one
stream the stream is closed before finalize. If -a is used to open more
than one stream finalize is used without closing the streams first
 - Option -k is changed to default ack when write
 - Option -e is added. Means exit without closing streams or finalize 
lgs
API (for testing client loss)
 - Option -o is added. Means, saflogtest will stop with streams open if 
any
key is pressed it will exit depending on other options.


Complete diffstat:
--
 tests/logsv/saflogtest.c |  342 
++
 1 files changed, 256 insertions(+), 86 deletions(-)


Testing Commands:
-
Run logtest


Testing, Expected Results:
--
Shall work with the new version of saflogtest tool


Conditions of Submission:
-
Pushed on thursday 19/12 2013


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.


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibili

Re: [devel] [PATCH 0 of 1] Review Request for base: use _Exit instead of exit in daemon_exit #581

2013-12-16 Thread Hans Nordebäck
Hi Ramesh, is it ok if I push this patch today?/BR HansN

-Original Message-
From: Anders Widell 
Sent: den 10 december 2013 10:42
To: Hans Nordebäck; Hans Feldt; ramesh.bet...@oracle.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 0 of 1] Review Request for base: use _Exit instead of exit 
in daemon_exit #581

Ack with comment. The ticket number is still not surrounded with square 
brackets [#581] in the first line of the commit message.

regards,
Anders Widell

2013-12-10 10:37, Hans Nordeback skrev:
> Summary: base: use _Exit instead of exit in daemon_exit [#581] Review 
> request for Trac Ticket(s): 581 Peer Reviewer(s): AndersW,HansF,Ramesh 
> Pull request to:
> Affected branch(es): default(4.4)
> 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  y
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>   <>
>
> changeset 8d36c7f02507201c39204ad7afc7574bb6cdc4a0
> Author:   Hans Nordeback 
> Date: Tue, 10 Dec 2013 10:24:37 +0100
>
>   base: use _Exit instead of exit in daemon_exit #581
>
>   use _Exit instead of exit in daemon_exit. The change was done due to 
> that
>   exit() is not thread safe, see e.g. ticket #651. To make it possible to 
> dump
>   e.g. coverage data on termination a weak reference to __gcov_flush has 
> been
>   added.
>
>
> Complete diffstat:
> --
>   osaf/libs/core/common/daemon.c |  8 +++-
>   1 files changed, 7 insertions(+), 1 deletions(-)
>
>
> Testing Commands:
> -
>   <>
>
>
> Testing, Expected Results:
> --
>   <>
>
>
> Conditions of Submission:
> -
>   <>
>
>
> 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 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.
>


--
Rapidly troubleshoot problems before they affect yo

Re: [devel] [PATCH 0 of 1] Review Request for logsv: Remove dependency to shared file system [#152]

2013-12-16 Thread Mathivanan Naickan Palanivelu
Hi Lennart,
I'm reviewing/testing this patch, will get back.
- Mathi.

> -Original Message-
> From: Lennart Lund [mailto:lennart.l...@ericsson.com]
> Sent: Monday, December 16, 2013 6:37 PM
> To: Lennart Lund; Mathivanan Naickan Palanivelu; Hans Feldt; Bertil
> Engelholm
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: RE: [devel] [PATCH 0 of 1] Review Request for logsv: Remove
> dependency to shared file system [#152]
> 
> Hi,
> 
> This will be pushed on Thursday if no comments
> 
> thanks
> Lennart
> 
> > -Original Message-
> > From: Lennart Lund [mailto:lennart.l...@ericsson.com]
> > Sent: den 12 december 2013 20:13
> > To: mathi.naic...@oracle.com; Hans Feldt; Bertil Engelholm
> > Cc: opensaf-devel@lists.sourceforge.net
> > Subject: [devel] [PATCH 0 of 1] Review Request for logsv: Remove
> > dependency to shared file system [#152]
> >
> > Summary: logsv: Remove dependency to shared file system Review
> request
> > for Trac Ticket(s): [#152] Peer Reviewer(s): Mathi N, Hans F, Bertil E
> > Pull request to: <> Affected
> > branch(es): 4.4 Development branch: <>
> >
> > 
> > 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 e6027497eb6deb93ebef06ed2e798607f0b71bf3
> > Author: Lennart Lund 
> > Date:   Thu, 12 Dec 2013 20:06:55 +0100
> >
> > logsv: Handle log files on both active and standby [#152]
> >
> > - Fix init of fd = 0 to fd = -1 in log_stream_new_2()
> >
> > - Add configuration attribute for activating split file system Config 1:
> > Use shared file system (default) Config 2: Split file system
> > - Remove IMM applier for lgs config Replace with checkpointing of
> > root path
> > - Add same file handling to Standby as active if configured to do so.
> > Reuse
> > evt processes, handle configuration attribute.
> > - Write log records to Standby if configured to do so
> > - On standby if config 2; Rotate files when current filename changes.
> > Also
> > rotate if file has reached max size. In that case create filename
> > based on
> > standby node clock.
> >
> >
> > Complete diffstat:
> > --
> >  osaf/services/saf/logsv/config/logsv_classes.xml |9 ++-
> >  osaf/services/saf/logsv/lgs/lgs.h|   11 ++-
> >  osaf/services/saf/logsv/lgs/lgs_amf.c|6 +-
> >  osaf/services/saf/logsv/lgs/lgs_evt.c|  109 
> > --
> --
> > 
> >  osaf/services/saf/logsv/lgs/lgs_evt.h|4 +-
> >  osaf/services/saf/logsv/lgs/lgs_file.c   |3 -
> >  osaf/services/saf/logsv/lgs/lgs_imm.c|  263
> > ++---
> >  osaf/services/saf/logsv/lgs/lgs_main.c   |7 -
> >  osaf/services/saf/logsv/lgs/lgs_mbcsv.c  |  253
> >
> ++
> > +---
> >  osaf/services/saf/logsv/lgs/lgs_mbcsv.h  |   25 +-
> >  osaf/services/saf/logsv/lgs/lgs_stream.c |  404
> >
> ++
> > 
> >  osaf/services/saf/logsv/lgs/lgs_stream.h |   28 ++-
> >  osaf/services/saf/logsv/lgs/lgs_util.c   |   43 +--
> >  osaf/services/saf/logsv/lgs/lgs_util.h   |5 +-
> >  14 files changed, 826 insertions(+), 344 deletions(-)
> >
> >
> > Testing Commands:
> > -
> > Regression test:
> > Use logtest in both shared and split file system configuration.
> > For more information see README file
> >
> >
> > Testing, Expected Results:
> > --
> > > logtest
> > All tests shall pass
> >
> >
> > 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 pat

Re: [devel] [PATCH 0 of 1] Review Request for logsv: Remove dependency to shared file system [#152]

2013-12-16 Thread Lennart Lund
Hi,

This will be pushed on Thursday if no comments 

thanks
Lennart

> -Original Message-
> From: Lennart Lund [mailto:lennart.l...@ericsson.com]
> Sent: den 12 december 2013 20:13
> To: mathi.naic...@oracle.com; Hans Feldt; Bertil Engelholm
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [devel] [PATCH 0 of 1] Review Request for logsv: Remove
> dependency to shared file system [#152]
> 
> Summary: logsv: Remove dependency to shared file system Review request
> for Trac Ticket(s): [#152] Peer Reviewer(s): Mathi N, Hans F, Bertil E Pull
> request to: <> Affected
> branch(es): 4.4 Development branch: <>
> 
> 
> 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 e6027497eb6deb93ebef06ed2e798607f0b71bf3
> Author:   Lennart Lund 
> Date: Thu, 12 Dec 2013 20:06:55 +0100
> 
>   logsv: Handle log files on both active and standby [#152]
> 
>   - Fix init of fd = 0 to fd = -1 in log_stream_new_2()
> 
>   - Add configuration attribute for activating split file system Config 1:
>   Use shared file system (default) Config 2: Split file system
>   - Remove IMM applier for lgs config Replace with checkpointing of
> root path
>   - Add same file handling to Standby as active if configured to do so.
> Reuse
>   evt processes, handle configuration attribute.
>   - Write log records to Standby if configured to do so
>   - On standby if config 2; Rotate files when current filename changes.
> Also
>   rotate if file has reached max size. In that case create filename based
> on
>   standby node clock.
> 
> 
> Complete diffstat:
> --
>  osaf/services/saf/logsv/config/logsv_classes.xml |9 ++-
>  osaf/services/saf/logsv/lgs/lgs.h|   11 ++-
>  osaf/services/saf/logsv/lgs/lgs_amf.c|6 +-
>  osaf/services/saf/logsv/lgs/lgs_evt.c|  109 
> 
> 
>  osaf/services/saf/logsv/lgs/lgs_evt.h|4 +-
>  osaf/services/saf/logsv/lgs/lgs_file.c   |3 -
>  osaf/services/saf/logsv/lgs/lgs_imm.c|  263
> ++---
>  osaf/services/saf/logsv/lgs/lgs_main.c   |7 -
>  osaf/services/saf/logsv/lgs/lgs_mbcsv.c  |  253
> ++
> +---
>  osaf/services/saf/logsv/lgs/lgs_mbcsv.h  |   25 +-
>  osaf/services/saf/logsv/lgs/lgs_stream.c |  404
> ++
> 
>  osaf/services/saf/logsv/lgs/lgs_stream.h |   28 ++-
>  osaf/services/saf/logsv/lgs/lgs_util.c   |   43 +--
>  osaf/services/saf/logsv/lgs/lgs_util.h   |5 +-
>  14 files changed, 826 insertions(+), 344 deletions(-)
> 
> 
> Testing Commands:
> -
> Regression test:
> Use logtest in both shared and split file system configuration.
> For more information see README file
> 
> 
> Testing, Expected Results:
> --
> > logtest
> All tests shall pass
> 
> 
> 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 cha

Re: [devel] [PATCH 1 of 1] IMM: Update the README file to document NO_DANGLING [#635]

2013-12-16 Thread Anders Bjornerstedt
Ok.
Will add information about A.2.13 being needed for use of NO_DANGLING.
And push this.

Zoran is just about ready to send out the patch for #50 (search API for 
NO_DANGLING) for review.

http://sourceforge.net/p/opensaf/tickets/50/

In will send out an update for README.NO_DANGLING to be part of that review.

/AndersBj



Neelakanta Reddy wrote:
> Hi AndersBj,
>
> Reviewed the patch.
> Ack with minor commnet.
>
> comment:
>
> supporting imm version must be included in the readme for No_DANGLING.
>
> /Neel.
> On Monday 02 December 2013 09:11 PM, Anders Bjornerstedt wrote:
>>   osaf/services/saf/immsv/README |   14 +++-
>>   osaf/services/saf/immsv/README.2PBE|   20 +++--
>>   osaf/services/saf/immsv/README.NO_DANGLING |  113 
>> +
>>   3 files changed, 137 insertions(+), 10 deletions(-)
>>
>>
>> Also updated README.2PBE with a pointer to always at least provide 
>> the imm.xml
>> file at both SCs, when initial start is to be be performed for a 2PBE 
>> cluster.
>>
>> 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
>> @@ -1606,12 +1606,22 @@ Bit 4 controls 2PBE oneSAfe2PBE (see 2PB
>> 2PBE Allow IMM PBE to be configured without shared file system (4.4)
>>   ===
>> -https://sourceforge.net/p/opensaf/tickets/21/
>> +http://sourceforge.net/p/opensaf/tickets/21/
>> The 2PBE enhancement allows the IMM to have PBE configred so that it
>>   does not rely on a shared filesystem, such as DRBD.
>> -See: osaf/services/saf/immsv/README.2PBE.
>>   +See: osaf/services/saf/immsv/README.2PBE for details.
>> +
>> +
>> +Support for reference integrity checking - SA_IMM_ATTR_NO_DANGLING 
>> (4.4)
>> + 
>>
>> +http://sourceforge.net/p/opensaf/tickets/49/
>> +
>> +A new attribute definition flag has been defined:
>> +#define SA_IMM_ATTR_NO_DANGLING   0x0400
>> +
>> +See: osaf/services/saf/immsv/README.NO_DANGLING for details.
>> 
>>   DEPENDENCIES
>> diff --git a/osaf/services/saf/immsv/README.2PBE 
>> b/osaf/services/saf/immsv/README.2PBE
>> --- a/osaf/services/saf/immsv/README.2PBE
>> +++ b/osaf/services/saf/immsv/README.2PBE
>> @@ -66,7 +66,16 @@ Cluster-start & IMM loading from PBE-fil
>>   The active IMMD will order each SC resident IMMND to execute a 
>> "preload", probing
>>   the SC local filesystem for the file state that *would* be loaded 
>> to the cluster
>>   if that SC IMMND was chosen as coord. The two SC IMMNDs send the 
>> preload stats to
>> -the active IMMD.
>> +the active IMMD. On each SC, the file probe starts by attempting to 
>> open the
>> +database file with the 2PBE suffix (e.g. imm.db.2010f at SC1 and 
>> imm.db.2020f at
>> +SC2). If the file with suffix does not exist (can not be opened), 
>> then a new probe
>> +is tried using the database file without suffix (e.g imm.db at both 
>> SC1 and SC2).
>> +If that probe also fails, then the last alternative is to try to 
>> open the
>> +IMMSV_LOAD_FILE (e.g. imm.xml).
>> +
>> +When initial starting a 2PBE system, take care so that at least the 
>> imm.xml file
>> +exists at both SCs. Otherwise there is a risk that the preloading 
>> will hang for
>> +quite some time, when the IMMND restarts at an SC.
>> The active IMMD will wait for the IMMNDs at *both* SCs to 
>> complete the preload
>>   task and then determine which SC has the apparently latest file 
>> state. The IMMND
>> @@ -135,20 +144,15 @@ has synced (regenerated its file) and re
>> The 1safe2PBE state is entered by the administrative opeation:
>>   -  immadm -o 1 -a safImmService -p 
>> opensafImmNostdFlags:SA_UINT32_T:8 \
>> +  immadm -o 1 -p opensafImmNostdFlags:SA_UINT32_T:8 \
>>opensafImm=opensafImm,safApp=safImmService
>> It is exited either automatically by a rejoined SC or by an 
>> explicit administrative
>>   opertion:
>>   -  immadm -o 2 -a safImmService -p 
>> opensafImmNostdFlags:SA_UINT32_T:8 \
>> +  immadm -o 2 -p opensafImmNostdFlags:SA_UINT32_T:8 \
>>opensafImm=opensafImm,safApp=safImmService
>>   -Note the explicit setting of admin-owner-name using "-a 
>> safImmService". This has to
>> -be used for these admin-operations because the imm service needs 
>> admin-ownership
>> -over the object "opensafImm=opensafImm,safApp=safImmService" in 
>> order for 2PBE to
>> -work properly.
>> -
>>   Hence the fourth bit in the opensafImmNostdFlags bitvector of the 
>> OpenSAF service
>>   object, is used to toggle on/off oneSafe2PBE. Toggling this bit, on 
>> older systems,
>>   or systems that do not have 2PBE configured, will have no effect. 
>> Toggling this bit
>> diff --git a/osaf/services/saf/immsv/README.NO_DANGLING 
>> b/osaf/services/saf/immsv/README.NO_DANGLING
>> new file mode 100644
>> --- /d

Re: [devel] [PATCH 1 of 1] IMM: Update the README file to document NO_DANGLING [#635]

2013-12-16 Thread Neelakanta Reddy
Hi AndersBj,

Reviewed the patch.
Ack with minor commnet.

comment:

supporting imm version must be included in the readme for No_DANGLING.

/Neel.
On Monday 02 December 2013 09:11 PM, Anders Bjornerstedt wrote:
>   osaf/services/saf/immsv/README |   14 +++-
>   osaf/services/saf/immsv/README.2PBE|   20 +++--
>   osaf/services/saf/immsv/README.NO_DANGLING |  113 
> +
>   3 files changed, 137 insertions(+), 10 deletions(-)
>
>
> Also updated README.2PBE with a pointer to always at least provide the imm.xml
> file at both SCs, when initial start is to be be performed for a 2PBE cluster.
>
> 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
> @@ -1606,12 +1606,22 @@ Bit 4 controls 2PBE oneSAfe2PBE (see 2PB
>   
>   2PBE Allow IMM PBE to be configured without shared file system (4.4)
>   ===
> -https://sourceforge.net/p/opensaf/tickets/21/
> +http://sourceforge.net/p/opensaf/tickets/21/
>   
>   The 2PBE enhancement allows the IMM to have PBE configred so that it
>   does not rely on a shared filesystem, such as DRBD.
> -See: osaf/services/saf/immsv/README.2PBE.
>   
> +See: osaf/services/saf/immsv/README.2PBE for details.
> +
> +
> +Support for reference integrity checking - SA_IMM_ATTR_NO_DANGLING (4.4)
> +
> +http://sourceforge.net/p/opensaf/tickets/49/
> +
> +A new attribute definition flag has been defined:
> +#define SA_IMM_ATTR_NO_DANGLING   0x0400
> +
> +See: osaf/services/saf/immsv/README.NO_DANGLING for details.
>   
>   
>   DEPENDENCIES
> diff --git a/osaf/services/saf/immsv/README.2PBE 
> b/osaf/services/saf/immsv/README.2PBE
> --- a/osaf/services/saf/immsv/README.2PBE
> +++ b/osaf/services/saf/immsv/README.2PBE
> @@ -66,7 +66,16 @@ Cluster-start & IMM loading from PBE-fil
>   The active IMMD will order each SC resident IMMND to execute a "preload", 
> probing
>   the SC local filesystem for the file state that *would* be loaded to the 
> cluster
>   if that SC IMMND was chosen as coord. The two SC IMMNDs send the preload 
> stats to
> -the active IMMD.
> +the active IMMD. On each SC, the file probe starts by attempting to open the
> +database file with the 2PBE suffix (e.g. imm.db.2010f at SC1 and 
> imm.db.2020f at
> +SC2). If the file with suffix does not exist (can not be opened), then a new 
> probe
> +is tried using the database file without suffix (e.g imm.db at both SC1 and 
> SC2).
> +If that probe also fails, then the last alternative is to try to open the
> +IMMSV_LOAD_FILE (e.g. imm.xml).
> +
> +When initial starting a 2PBE system, take care so that at least the imm.xml 
> file
> +exists at both SCs. Otherwise there is a risk that the preloading will hang 
> for
> +quite some time, when the IMMND restarts at an SC.
>   
>   The active IMMD will wait for the IMMNDs at *both* SCs to complete the 
> preload
>   task and then determine which SC has the apparently latest file state. The 
> IMMND
> @@ -135,20 +144,15 @@ has synced (regenerated its file) and re
>   
>   The 1safe2PBE state is entered by the administrative opeation:
>   
> -  immadm -o 1 -a safImmService -p opensafImmNostdFlags:SA_UINT32_T:8 \
> +  immadm -o 1 -p opensafImmNostdFlags:SA_UINT32_T:8 \
>opensafImm=opensafImm,safApp=safImmService
>   
>   It is exited either automatically by a rejoined SC or by an explicit 
> administrative
>   opertion:
>   
> -  immadm -o 2 -a safImmService -p opensafImmNostdFlags:SA_UINT32_T:8 \
> +  immadm -o 2 -p opensafImmNostdFlags:SA_UINT32_T:8 \
>opensafImm=opensafImm,safApp=safImmService
>   
> -Note the explicit setting of admin-owner-name using "-a safImmService". This 
> has to
> -be used for these admin-operations because the imm service needs 
> admin-ownership
> -over the object "opensafImm=opensafImm,safApp=safImmService" in order for 
> 2PBE to
> -work properly.
> -
>   Hence the fourth bit in the opensafImmNostdFlags bitvector of the OpenSAF 
> service
>   object, is used to toggle on/off oneSafe2PBE. Toggling this bit, on older 
> systems,
>   or systems that do not have 2PBE configured, will have no effect. Toggling 
> this bit
> diff --git a/osaf/services/saf/immsv/README.NO_DANGLING 
> b/osaf/services/saf/immsv/README.NO_DANGLING
> new file mode 100644
> --- /dev/null
> +++ b/osaf/services/saf/immsv/README.NO_DANGLING
> @@ -0,0 +1,113 @@
> +Support for reference integrity checking - SA_IMM_ATTR_NO_DANGLING (4.4)
> +
> +http://sourceforge.net/p/opensaf/tickets/49/
> +
> +A new attribute definition flag has been defined:
> +#define SA_IMM_ATTR_NO_DANGLING   0x0400
> +
> +This flag can only be set for attribute definitions where the attribute da

Re: [devel] [PATCH 0 of 3] Review Request for IMM: Implementation of NO_DANGLING flag [#49]

2013-12-16 Thread Neelakanta Reddy
Hi Zoran,

Reviewed and tested the patch.
Ack.

/Neel.
On Thursday 05 December 2013 08:34 PM, Zoran Milinkovic wrote:
> Summary: IMM: Implementation of NO_DANGLING flag [#49]
> Review request for Trac Ticket(s): 49
> Peer Reviewer(s): Neelakanta, Anders
> Pull request to: Zoran
> Affected branch(es): default(4.4)
> Development branch: default(4.4)
>
> 
> 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 262748c382d21cb6ec391e1b1fcf4a8a1e6256ae
> Author:   Zoran Milinkovic 
> Date: Thu, 05 Dec 2013 15:56:17 +0100
>
>   IMM: API support for NO_DANGLING flag [#49]
>
>   IMM API support for reference integrity (NO_DANGLING flag)
>
> changeset 121f26d8504c86c63643c03bb81840460e66a69b
> Author:   Zoran Milinkovic 
> Date: Thu, 05 Dec 2013 15:57:11 +0100
>
>   IMM: IMM service implementation of NO_DANGLING flag [#49]
>
>   Implementation of reference integrity (NO_DANGLING flag) to IMMSV
>
> changeset 68c4e3d7d6b3c3a501c20903fc63d9ba8a125420
> Author:   Zoran Milinkovic 
> Date: Thu, 05 Dec 2013 15:58:25 +0100
>
>   IMMTOOLS: Add support of NO_DANGLING flag to IMM tools [#49]
>
>   Support reference integrity (NO_DANGLING flag) to IMM tools
>
>
> Added Files:
> 
>   osaf/libs/saf/include/saImmOm_A_2_13.h
>   osaf/services/saf/immsv/schema/SAI-AIS-IMM-XSD-A.02.13.xsd
>
>
> Complete diffstat:
> --
>   osaf/libs/agents/saf/imma/imma_om_api.c|   36 -
>   osaf/libs/common/immsv/include/immpbe_dump.hh  |2 +-
>   osaf/libs/common/immsv/include/immsv_api.h |9 +
>   osaf/libs/saf/include/Makefile.am  |3 +-
>   osaf/libs/saf/include/saImmOm_A_2_12.h |2 +
>   osaf/libs/saf/include/saImmOm_A_2_13.h |   60 +
>   osaf/libs/saf/libSaImm/Makefile.am |2 +-
>   osaf/services/saf/immsv/immloadd/imm_loader.cc |8 +-
>   osaf/services/saf/immsv/immloadd/imm_pbe_load.cc   |2 +-
>   osaf/services/saf/immsv/immnd/ImmAttrValue.cc  |6 +
>   osaf/services/saf/immsv/immnd/ImmAttrValue.hh  |2 +
>   osaf/services/saf/immsv/immnd/ImmModel.cc  |  950 
> +++--
>   osaf/services/saf/immsv/immnd/ImmModel.hh  |   37 +-
>   osaf/services/saf/immsv/schema/SAI-AIS-IMM-XSD-A.02.13.xsd |  180 
> +++
>   osaf/tools/safimm/immcfg/imm_import.cc |2 +
>   osaf/tools/safimm/immdump/imm_xmlw_dump.cc |9 +
>   osaf/tools/safimm/immlist/imm_list.c   |3 +
>   17 files changed, 1231 insertions(+), 82 deletions(-)
>
>
> Testing Commands:
> -
>
>
> Testing, Expected Results:
> --
> The patches need to support:
> - immload support for NO_DANGLING flag
> - immdump support for NO_DANGLING flag
> - immcfg support for NO_DANGLING flag (immcfg -f)
> - immlist support for NO_DANGLING flag (NO_DANGLING flag is listed)
> - IMM library support for NO_DANGLING (classCreate - basic checks)
> - schema update (adding and removing NO_DANGLING flag)
> - default values
> - create object (NO_DANGLING attributes with and without values)
> - modify object (add, replace and delete)
> - delete object
> - CCB apply
> - CCB abort/terminate
> - support for missing objects, created later within the same CCB
>
>
> Conditions of Submission:
> -
> Ack from Neelakanta and Anders
>
>
> 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 heade

Re: [devel] [PATCH 0 of 2] Review Request for MDS #654

2013-12-16 Thread Hans Feldt
Additional info, I easily got overload executing saflogtest on the single 
cluster node. This was on Ubuntu 12.04 with a 
3.2.0 kernel which still has the node overload limit. See socket.c and 
OVERLOAD_LIMIT_BASE and tipc_queue_size

the logic in 3.2.0 TIPC looks like:

> recv_q_len = (u32)atomic_read(&tipc_queue_size);
> if (unlikely(recv_q_len >= OVERLOAD_LIMIT_BASE)) {  
> <== node limit
> if (rx_queue_full(msg, recv_q_len, OVERLOAD_LIMIT_BASE))
> return TIPC_ERR_OVERLOAD;
> }
> recv_q_len = skb_queue_len(&sk->sk_receive_queue); 
> <=== per socket limit
> if (unlikely(recv_q_len >= (OVERLOAD_LIMIT_BASE / 2))) {
> if (rx_queue_full(msg, recv_q_len, OVERLOAD_LIMIT_BASE / 2))
> return TIPC_ERR_OVERLOAD;
> }

OVERLOAD_LIMIT_BASE is 5000 in this kernel. So bursting 1 could easily hit 
the node limit. After that you would hit 
the per socket message limit which is 5000/2 for LOW importance messages. And 
last the socket receive buffer size which 
seems to be 229376 (default) on this system.

/Hans


On 12/16/2013 10:53 AM, Hans Feldt wrote:
> Summary: MDS improvements
> Review request for Trac Ticket(s): 654
> Peer Reviewer(s): Mahesh, Surya
> 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  y
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>
> Second version of the TIPC_DEST_DROPPABLE patch, the first one was missing
> a mutex unlock just before "continue".
>
> changeset 3f0e45599ac09117b73cf609a887a53eee0ff17b
> Author:   Hans Feldt 
> Date: Mon, 16 Dec 2013 10:15:50 +0100
>
>   mds: log cmdline at start [#654]
>
> changeset 4ab259f338d3c43108bad3e3ce88a6000749dafd
> Author:   Hans Feldt 
> Date: Mon, 16 Dec 2013 10:46:12 +0100
>
>   mds: set TIPC_DEST_DROPPABLE=false and log rejected msgs [#654]
>
>   By default TIPC_DEST_DROPPABLE=True for RDM TIPC sockets. If there is
>   congestion on the receiving node, the message will be silently dropped 
> by
>   TIPC. This can cause unknown consequences for OpenSAF services.
>
>   Ideally MDS should retransmit lost messages but in this patch
>   TIPC_DEST_DROPPABLE is turned off just for diagnostics purposes. All 
> logging
>   is done to the mds log since it would be possible to get returned 
> messages
>   just for timing reasons (a process dies) and not overload.
>
>   Note that there are no guarantess that a message can be returned. So the
>   absence of rejected messages does not guarantee anything.
>
>
> Complete diffstat:
> --
>   osaf/libs/core/mds/include/mds_dt.h |2 +-
>   osaf/libs/core/mds/mds_dt_common.c  |2 +-
>   osaf/libs/core/mds/mds_dt_tipc.c|  115 
> +--
>   osaf/libs/core/mds/mds_main.c   |   10 ++
>   4 files changed, 113 insertions(+), 16 deletions(-)
>
>
> Testing Commands:
> -
>   Start a one node cluster using TIPC
>   exec: saflogtest -c 1
>
>
> Testing, Expected Results:
> --
>   syslog entries:
>
>   Dec 16 10:44:07 saflogtest: MDS: TIPC message rejected, reason:4, 
> portid:<0x01001001:d8b5a00f>
>   Dec 16 10:44:08 saflogtest: last message repeated 65 times
>
>   mds.log entries:
>
>   Dec 16 10:44:07.007809 <3635781675> NOTIFY |BEGIN MDS LOGGING| 
> PID=5974|ARCH=0|64bit=1
> Dec 16 10:44:07.008023 <3635781675> NOTIFY |cmdline=saflogtest 
> <=== NEW
> Dec 16 10:44:07.008145 <3635781675> NOTIFY |MDTM: install_tipc : svc id=21, 
> vdest=65535
> Dec 16 10:44:07.008173 <3635781647> NOTIFY |MDTM: svc up event for SVCid =21, 
> subscri. by SVCid =20 pwe_id=1 adest=0002010fd8b5a02b
> Dec 16 10:44:07.008323 <3635781675> NOTIFY |MDTM: svc up event for SVCid =20, 
> subscri. by SVCid =21 pwe_id=1 adest=0002010fd8b5a00f
> Dec 16 10:44:07.008385 <3635781675> NOTIFY |MDTM: svc up event for SVCid =20, 
> subscri. by SVCid =21 pwe_id=1 adest=0002010fd8b5a00f
> Dec 16 10:44:07.026063 <3635781675> ERR|MDTM: MSG Rejected, 
> reason=OVERLOAD, TIPC PortId=01001001:d8b5a00f, sz=117
> Dec 16 10:44:07.026118 <3635781675> ERR|DUMP:buff=0x6d770058:offset=  0 
> to   7:Bytes = 0x00 0x75 0x00 0x00 : 0x11 0x52 0x00 0x00
> Dec 16 10:44:07.026149 <3635781675> ERR|DUMP:buff=0x6d770058:offset=  8 
> to  15:Bytes 

[devel] [PATCH 2 of 2] mds: set TIPC_DEST_DROPPABLE=false and log rejected msgs [#654]

2013-12-16 Thread Hans Feldt
 osaf/libs/core/mds/mds_dt_tipc.c |  115 ++
 1 files changed, 101 insertions(+), 14 deletions(-)


By default TIPC_DEST_DROPPABLE=True for RDM TIPC sockets. If there is congestion
on the receiving node, the message will be silently dropped by TIPC. This can
cause unknown consequences for OpenSAF services.

Ideally MDS should retransmit lost messages but in this patch
TIPC_DEST_DROPPABLE is turned off just for diagnostics purposes. All logging is
done to the mds log since it would be possible to get returned messages just for
timing reasons (a process dies) and not overload.

Note that there are no guarantess that a message can be returned. So the absence
of rejected messages does not guarantee anything.

diff --git a/osaf/libs/core/mds/mds_dt_tipc.c b/osaf/libs/core/mds/mds_dt_tipc.c
--- a/osaf/libs/core/mds/mds_dt_tipc.c
+++ b/osaf/libs/core/mds/mds_dt_tipc.c
@@ -24,12 +24,6 @@
 
 **
 */
-#include "mds_dt.h"
-#include "mds_log.h"
-#include "ncssysf_def.h"
-#include "ncssysf_tsk.h"
-#include "ncssysf_mem.h"
-
 #include 
 #include 
 #include 
@@ -37,6 +31,13 @@
 #include 
 #include 
 #include 
+#include 
+
+#include "mds_dt.h"
+#include "mds_log.h"
+#include "ncssysf_def.h"
+#include "ncssysf_tsk.h"
+#include "ncssysf_mem.h"
 #include "mds_dt_tipc.h"
 #include "mds_core.h"
 #include "osaf_utility.h"
@@ -180,6 +181,15 @@ uint32_t mdtm_tipc_init(NODE_ID nodeid, 
return NCSCC_RC_FAILURE;
}
 
+   // To avoid silent dropping of messages due to message rejection,
+   // configure TIPC to return rejected messages to the sender.
+   // See "Message Rejection" in TIPC PG
+   const int off = 0;
+   if (setsockopt(tipc_cb.BSRsock, SOL_TIPC, TIPC_DEST_DROPPABLE, &off, 
sizeof(off)) != 0) {
+   syslog(LOG_ERR, "MDS:MDTM:TIPC BSRsock Socket setsockopt 
DROPPABLE failed - %s", strerror(errno));
+   return EXIT_FAILURE;
+   }
+
flags = fcntl(tipc_cb.Dsock, F_GETFD, 0);
if ((flags < 0) || (flags > 1)) {
syslog(LOG_ERR, "MDS:MDTM:TIPC Unable to get the CLOEXEC Flag 
on Dsock err :%s", strerror(errno));
@@ -543,6 +553,74 @@ static uint32_t mdtm_destroy_rcv_task(vo
 
 }
 
+/**
+ * receive message and ancillary data from socket, log ancillary data
+ * @param sd
+ * @param buf
+ * @param nbytes
+ * @param flags
+ * @param from
+ * @return same as recvmsg
+ */
+static ssize_t recvfrom_anc(int sd, void *buf, size_t nbytes, int flags,
+struct sockaddr_tipc *from, uint32_t *reject_reason)
+{
+   struct msghdr msg;
+   struct iovec iov;
+   char *anc_buf[CMSG_SPACE(8) + CMSG_SPACE(1024) + CMSG_SPACE(12)];
+
+   msg.msg_iov = &iov;
+   msg.msg_iovlen = 1;
+   msg.msg_name = (struct sockaddr *)from;
+   msg.msg_namelen = sizeof(struct sockaddr_tipc);
+   msg.msg_control = anc_buf;
+   msg.msg_controllen = sizeof(anc_buf);
+   iov.iov_base = buf;
+   iov.iov_len = nbytes;
+
+   ssize_t sz = recvmsg(sd, &msg, flags);
+
+   // TIPC PG: for a connectionless socket, a return value of 0 indicates 
the
+   // arrival of a returned data message that was originally sent by this 
socket.
+
+   if (sz == 0) {
+   struct cmsghdr *anc;
+   unsigned char *cptr;
+   uint32_t *iptr;
+
+   // log ancillary data for diagnostics
+
+   anc = CMSG_FIRSTHDR(&msg);
+   while (anc != NULL) {
+   cptr = CMSG_DATA(anc);
+
+   if (anc->cmsg_type == TIPC_ERRINFO) {
+   iptr = (uint32_t *)cptr;
+   *reject_reason = iptr[0];
+   if (iptr[0] == TIPC_ERR_OVERLOAD)
+   m_MDS_LOG_ERR("MDTM: MSG Rejected, 
reason=OVERLOAD, TIPC PortId=%08x:%x, sz=%u\n",
+   from->addr.id.node, 
from->addr.id.ref, iptr[1]);
+   else
+   m_MDS_LOG_ERR("MDTM: MSG Rejected, 
reason=<%u>, TIPC PortId=%08x:%x, sz=%u\n",
+   iptr[0], 
from->addr.id.node, from->addr.id.ref, iptr[1]);
+   } else if (anc->cmsg_type == TIPC_RETDATA) {
+   mds_buff_dump(cptr, anc->cmsg_len - 
sizeof(*anc), 128);
+   } else if (anc->cmsg_type == TIPC_DESTNAME) {
+   iptr = (__u32 *)cptr;
+   m_MDS_LOG_ERR("MDTM: MSG Rejected: destination 
name = {%x,%x,%x}\n",
+   iptr[0], iptr[1], iptr[2]);
+   } else {
+   m_MDS_LOG_ERR("MDTM: MSG Rejected: unrecognized 
ancillary data type %u\n",
+  

[devel] [PATCH 1 of 2] mds: log cmdline at start [#654]

2013-12-16 Thread Hans Feldt
 osaf/libs/core/mds/include/mds_dt.h |   2 +-
 osaf/libs/core/mds/mds_dt_common.c  |   2 +-
 osaf/libs/core/mds/mds_main.c   |  10 ++
 3 files changed, 12 insertions(+), 2 deletions(-)


diff --git a/osaf/libs/core/mds/include/mds_dt.h 
b/osaf/libs/core/mds/include/mds_dt.h
--- a/osaf/libs/core/mds/include/mds_dt.h
+++ b/osaf/libs/core/mds/include/mds_dt.h
@@ -206,7 +206,7 @@ typedef struct mdtm_ref_hdl_list {
 
 MDTM_REF_HDL_LIST *mdtm_ref_hdl_list_hdr;
 uint32_t mdtm_attach_mbx(SYSF_MBX mbx);
-void mds_buff_dump(uint8_t *buff, uint32_t len, uint32_t max);
+void mds_buff_dump(const uint8_t *buff, uint32_t len, uint32_t max);
 NCS_PATRICIA_TREE mdtm_reassembly_list;
 
 uint32_t mdtm_set_transport(MDTM_TX_TYPE transport);
diff --git a/osaf/libs/core/mds/mds_dt_common.c 
b/osaf/libs/core/mds/mds_dt_common.c
--- a/osaf/libs/core/mds/mds_dt_common.c
+++ b/osaf/libs/core/mds/mds_dt_common.c
@@ -1258,7 +1258,7 @@ static uint32_t mdtm_del_reassemble_queu
return NCSCC_RC_SUCCESS;
 }
 
-void mds_buff_dump(uint8_t *buff, uint32_t len, uint32_t max)
+void mds_buff_dump(const uint8_t *buff, uint32_t len, uint32_t max)
 {
int offset;
uint8_t last_line[8];
diff --git a/osaf/libs/core/mds/mds_main.c b/osaf/libs/core/mds/mds_main.c
--- a/osaf/libs/core/mds/mds_main.c
+++ b/osaf/libs/core/mds/mds_main.c
@@ -290,6 +290,16 @@ uint32_t mds_lib_req(NCS_LIB_REQ_INFO *r
snprintf(buff, sizeof(buff), PKGLOGDIR "/mds.log");
snprintf(pref, sizeof(pref), "<%u>", mds_tipc_ref);
mds_log_init(buff, pref);
+
+   FILE *f = fopen("/proc/self/cmdline", "r");
+   if (f != NULL) {
+   char cmdline[128];
+   size_t sz = fread(cmdline, 1, sizeof(cmdline), 
f);
+   if (sz) {
+   log_mds_notify("cmdline=%s", cmdline);
+   }
+   fclose(f);
+   }
}
 
osaf_mutex_unlock_ordie(&gl_mds_library_mutex);

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 0 of 2] Review Request for MDS #654

2013-12-16 Thread Hans Feldt
Summary: MDS improvements
Review request for Trac Ticket(s): 654
Peer Reviewer(s): Mahesh, Surya
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  y
 Samples n
 Tests   n
 Other   n


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

Second version of the TIPC_DEST_DROPPABLE patch, the first one was missing
a mutex unlock just before "continue".

changeset 3f0e45599ac09117b73cf609a887a53eee0ff17b
Author: Hans Feldt 
Date:   Mon, 16 Dec 2013 10:15:50 +0100

mds: log cmdline at start [#654]

changeset 4ab259f338d3c43108bad3e3ce88a6000749dafd
Author: Hans Feldt 
Date:   Mon, 16 Dec 2013 10:46:12 +0100

mds: set TIPC_DEST_DROPPABLE=false and log rejected msgs [#654]

By default TIPC_DEST_DROPPABLE=True for RDM TIPC sockets. If there is
congestion on the receiving node, the message will be silently dropped 
by
TIPC. This can cause unknown consequences for OpenSAF services.

Ideally MDS should retransmit lost messages but in this patch
TIPC_DEST_DROPPABLE is turned off just for diagnostics purposes. All 
logging
is done to the mds log since it would be possible to get returned 
messages
just for timing reasons (a process dies) and not overload.

Note that there are no guarantess that a message can be returned. So the
absence of rejected messages does not guarantee anything.


Complete diffstat:
--
 osaf/libs/core/mds/include/mds_dt.h |2 +-
 osaf/libs/core/mds/mds_dt_common.c  |2 +-
 osaf/libs/core/mds/mds_dt_tipc.c|  115 
+--
 osaf/libs/core/mds/mds_main.c   |   10 ++
 4 files changed, 113 insertions(+), 16 deletions(-)


Testing Commands:
-
 Start a one node cluster using TIPC
 exec: saflogtest -c 1


Testing, Expected Results:
--
 syslog entries:
 
 Dec 16 10:44:07 saflogtest: MDS: TIPC message rejected, reason:4, 
portid:<0x01001001:d8b5a00f>
 Dec 16 10:44:08 saflogtest: last message repeated 65 times

 mds.log entries:
 
 Dec 16 10:44:07.007809 <3635781675> NOTIFY |BEGIN MDS LOGGING| 
PID=5974|ARCH=0|64bit=1
Dec 16 10:44:07.008023 <3635781675> NOTIFY |cmdline=saflogtest 
<=== NEW
Dec 16 10:44:07.008145 <3635781675> NOTIFY |MDTM: install_tipc : svc id=21, 
vdest=65535
Dec 16 10:44:07.008173 <3635781647> NOTIFY |MDTM: svc up event for SVCid =21, 
subscri. by SVCid =20 pwe_id=1 adest=0002010fd8b5a02b
Dec 16 10:44:07.008323 <3635781675> NOTIFY |MDTM: svc up event for SVCid =20, 
subscri. by SVCid =21 pwe_id=1 adest=0002010fd8b5a00f
Dec 16 10:44:07.008385 <3635781675> NOTIFY |MDTM: svc up event for SVCid =20, 
subscri. by SVCid =21 pwe_id=1 adest=0002010fd8b5a00f
Dec 16 10:44:07.026063 <3635781675> ERR|MDTM: MSG Rejected, 
reason=OVERLOAD, TIPC PortId=01001001:d8b5a00f, sz=117
Dec 16 10:44:07.026118 <3635781675> ERR|DUMP:buff=0x6d770058:offset=  0 to  
 7:Bytes = 0x00 0x75 0x00 0x00 : 0x11 0x52 0x00 0x00
Dec 16 10:44:07.026149 <3635781675> ERR|DUMP:buff=0x6d770058:offset=  8 to  
15:Bytes = 0x00 0x6b 0xa9 0x00 : 0x18 0x00 0x00 0x11
Dec 16 10:44:07.026176 <3635781675> ERR|DUMP:buff=0x6d770058:offset= 16 to  
23:Bytes = 0x51 0x40 0x00 0x01 : 0xff 0xff 0x00 0x15
Dec 16 10:44:07.026202 <3635781675> ERR|DUMP:buff=0x6d770058:offset= 24 to  
31:Bytes = 0x00 0x0b 0x00 0x14 : 0x00 0x00 0x00 0x00
Dec 16 10:44:07.026228 <3635781675> ERR|DUMP:buff=0x6d770058:offset= 32 to  
39:Bytes = 0x00 0x01 0x00 0x00 : 0x00 0x00 0x00 0x00
Dec 16 10:44:07.026254 <3635781675> ERR|DUMP:buff=0x6d770058:offset= 40 to  
47:Bytes = 0x00 0x04 0x00 0x00 : 0x00 0x00 0x13 0xb5
Dec 16 10:44:07.026280 <3635781675> ERR|DUMP:buff=0x6d770058:offset= 48 to  
55:Bytes = 0x1f 0xf0 0x00 0x00 : 0x00 0x00 0x00 0x00
Dec 16 10:44:07.026307 <3635781675> ERR|DUMP:buff=0x6d770058:offset= 56 to  
63:Bytes = 0x00 0x06 0x00 0x00 : 0x00 0x02 0x13 0x40
Dec 16 10:44:07.026333 <3635781675> ERR|DUMP:buff=0x6d770058:offset= 64 to  
71:Bytes = 0x47 0x45 0x07 0x02 : 0x5a 0x58 0x00 0x00
Dec 16 10:44:07.026359 <3635781675> ERR|DUMP:buff=0x6d770058:offset= 72 to  
79:Bytes = 0x00 0x02 0x00 0x00 : 0x00 0x00 0x00 0x00
Dec 16 10:44:07.026385 <3635781675> ERR|DUMP:buff=0x6d770058:offset= 80 to  
87:Bytes = 0x00 0x00 0x00 0x1b : 0x73 0x61 0x66 0x6c
Dec 16 10:44:07.026411 <3635781675> ERR|DUMP:buff=0x6d770058:offset= 88 to  
95:Bytes = 0x6f 0x67 0x74 0x65 : 0x73 0x74 0x2e 0x35
Dec 16 10:44:07.026437 <

Re: [devel] [PATCH 0 of 3] Review Request for IMM: Add support for NO_DANGLING flag [#49]

2013-12-16 Thread Anders Bjornerstedt
Ack from me.

/AndersBj

Zoran Milinkovic wrote:
> Summary: IMM: Add support for NO_DANGLING flag [#49]
> Review request for Trac Ticket(s): 49
> Peer Reviewer(s): Neel, Anders
> Pull request to: Zoran
> Affected branch(es): default(4.4)
> Development branch: default(4.4)
>
> 
> 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 5581ca82a63f307e4a7e6427fd1d898a9505ea4a
> Author:   Zoran Milinkovic 
> Date: Sun, 15 Dec 2013 16:42:12 +0100
>
>   IMM: Add support for NO_DANGLING flag to API [#49]
>
> changeset d0d8baa7648c017838535aad044df58e3047afe2
> Author:   Zoran Milinkovic 
> Date: Sun, 15 Dec 2013 16:42:41 +0100
>
>   IMM: Add support for NO_DANGLING flag to the service [#49]
>
> changeset 073674c99718039ad86e50e499f1415bc365dfed
> Author:   Zoran Milinkovic 
> Date: Sun, 15 Dec 2013 16:43:09 +0100
>
>   IMMTOOLS: Add support for NO_DANGLING flag to tools [#49]
>
>
> Added Files:
> 
>  osaf/libs/saf/include/saImmOm_A_2_13.h
>  osaf/services/saf/immsv/schema/SAI-AIS-IMM-XSD-A.02.13.xsd
>
>
> Complete diffstat:
> --
>  opensaf.spec.in| 1 +
>  osaf/libs/agents/saf/imma/imma_cb.h| 1 +
>  osaf/libs/agents/saf/imma/imma_def.h   | 2 +-
>  osaf/libs/agents/saf/imma/imma_oi_api.c|12 +-
>  osaf/libs/agents/saf/imma/imma_om_api.c|58 ++-
>  osaf/libs/common/immsv/include/immpbe_dump.hh  | 2 +-
>  osaf/libs/common/immsv/include/immsv_api.h | 9 +
>  osaf/libs/saf/include/Makefile.am  | 3 +-
>  osaf/libs/saf/include/saImmOm_A_2_12.h | 2 +
>  osaf/libs/saf/include/saImmOm_A_2_13.h |60 
>  osaf/libs/saf/libSaImm/Makefile.am | 2 +-
>  osaf/services/saf/immsv/immloadd/imm_loader.cc | 8 +-
>  osaf/services/saf/immsv/immloadd/imm_pbe_load.cc   | 2 +-
>  osaf/services/saf/immsv/immnd/ImmAttrValue.hh  | 2 +
>  osaf/services/saf/immsv/immnd/ImmModel.cc  |  1034 
> +++-
>  osaf/services/saf/immsv/immnd/ImmModel.hh  |41 +-
>  osaf/services/saf/immsv/schema/SAI-AIS-IMM-XSD-A.02.13.xsd |   180 
> +
>  osaf/tools/safimm/immadm/imm_admin.c   | 2 +-
>  osaf/tools/safimm/immcfg/imm_cfg.c | 2 +-
>  osaf/tools/safimm/immcfg/imm_import.cc | 4 +-
>  osaf/tools/safimm/immdump/imm_dumper.cc| 2 +-
>  osaf/tools/safimm/immdump/imm_xmlw_dump.cc | 9 +
>  osaf/tools/safimm/immlist/imm_list.c   | 3 +
>  23 files changed, 1348 insertions(+), 93 deletions(-)
>
>
> Testing Commands:
> -
>
>
> Testing, Expected Results:
> --
> The patches need to support:
> - immload support for NO_DANGLING flag
> - immdump support for NO_DANGLING flag
> - immcfg support for NO_DANGLING flag (immcfg -f)
> - immlist support for NO_DANGLING flag (NO_DANGLING flag is listed)
> - IMM library support for NO_DANGLING (classCreate - basic checks)
> - schema update (adding and removing NO_DANGLING flag)
> - default values
> - create object (NO_DANGLING attributes with and without values)
> - modify object (add, replace and delete)
> - delete object
> - CCB apply
> - CCB abort/terminate
> - support for missing objects, created later in the same CCB
>
>
> Conditions of Submission:
> -
> Ack from Neel and Anders
>
>
> 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
>
> ___ Y