[devel] [PATCH 1 of 1] amfd: disallow delete of CtCs object if Ct maps to comp [#2428]

2017-04-14 Thread nagendra . k
 osaf/services/saf/amf/amfd/ctcstype.cc |  60 -
 1 files changed, 58 insertions(+), 2 deletions(-)


diff --git a/osaf/services/saf/amf/amfd/ctcstype.cc 
b/osaf/services/saf/amf/amfd/ctcstype.cc
--- a/osaf/services/saf/amf/amfd/ctcstype.cc
+++ b/osaf/services/saf/amf/amfd/ctcstype.cc
@@ -26,7 +26,7 @@
 #include 
 
 AmfDb *ctcstype_db = nullptr;
-
+static void find_ct_name_from_association(const SaNameT *haystack, SaNameT 
*dn, const char *needle);
 static void ctcstype_db_add(AVD_CTCS_TYPE *ctcstype)
 {
unsigned int rc = ctcstype_db->insert(ctcstype->name,ctcstype);
@@ -185,17 +185,73 @@ static SaAisErrorT ctcstype_ccb_complete
report_ccb_validation_error(opdata, "Modification of 
SaAmfCtCsType not supported");
break;
case CCBUTIL_DELETE:
+   AVD_CTCS_TYPE *ctcstype;
+   SaNameT ct_name;
+   AVD_COMP_TYPE *comp_type;
+   AVD_COMP *comp;
+   CcbUtilOperationData_t *t_opData;
+
+ctcstype = 
ctcstype_db->find(Amf::to_string(>objectName));
+if (ctcstype != nullptr) {
+   find_ct_name_from_association(>objectName, 
_name, ",safVersion");
+   TRACE("'%s'", ct_name.value);
+   comp_type = comptype_db->find(Amf::to_string(_name));
+   if ((comp_type) && (nullptr != 
comp_type->list_of_comp)) {
+   /* check whether there exists a delete 
operation for
+* each of the Comp in the comp_type list in 
the current CCB
+*/
+   bool comp_exist = false;
+   TRACE("SaAmfCompType '%s' has components", 
comp_type->name.value);
+   comp = comp_type->list_of_comp;
+   while (comp != nullptr) {
+   TRACE("%s", comp->comp_info.name.value);
+   t_opData = 
ccbutil_getCcbOpDataByDN(opdata->ccbId, >comp_info.name);
+   TRACE("%p", t_opData);
+   if ((t_opData == nullptr) || 
(t_opData->operationType != CCBUTIL_DELETE)) {
+   TRACE("Here %p", t_opData);
+   comp_exist = true;
+   break;
+   }
+   comp = comp->comp_type_list_comp_next;
+   }
+   if (comp_exist == true) {
+   rc = SA_AIS_ERR_BAD_OPERATION;
+   report_ccb_validation_error(opdata, 
"SaAmfCompType '%s' is in use", comp_type->name.value);
+   goto done;
+   }
+   } else
+   TRACE("SaAmfCompType '%p'. SaAmfCompType '%s' 
has no components", comp_type, ct_name.value);
+   }
rc = SA_AIS_OK;
break;
default:
osafassert(0);
break;
}
-
+done:
TRACE_LEAVE2("%u", rc);
return rc;
 }
 
+/**
+ * Initialize a DN by searching for needle in haystack where two times 
safVersion comes.
+ * @param haystack
+ * @param dn
+ * @param needle
+ * @note: 
"safSupportedCsType=safVersion=1\,safCSType=AmfDemo1,safVersion=1,safCompType=AmfDemo1"
 
+ */
+static void find_ct_name_from_association(const SaNameT *haystack, SaNameT 
*dn, const char *needle)
+{
+char *p;
+
+memset(dn, 0, sizeof(SaNameT));
+p = strstr((char*)haystack->value, needle);
+osafassert(p);
+   p++; /* Increament after comma (,) */
+dn->length = strlen(p);
+memcpy(dn->value, p, dn->length);
+}
+
 static void ctcstype_ccb_apply_cb(CcbUtilOperationData_t *opdata)
 {
AVD_CTCS_TYPE *ctcstype;

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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: disallow delete of CtCs object if Ct maps to comp [#2428]

2017-04-14 Thread nagendra . k
Summary: amfd: disallow delete of CtCs object if Ct maps to comp [#2428]
Review request for Trac Ticket(s): #2428
Peer Reviewer(s): Amf Dev
Pull request to: <>
Affected branch(es): All
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 6f1d4e05b4cdbd45dcc9c8cb461ed22ee5e52fc2
Author: Nagendra Kumar
Date:   Fri, 14 Apr 2017 18:49:49 +0530

amfd: disallow delete of CtCs object if Ct maps to comp [#2428]


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


Testing Commands:
-
As per ticket.


Testing, Expected Results:
--
Amfd shouldnot crash.

Conditions of Submission:
-
Ack

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.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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: correct loop variable initialization [#2404]

2017-04-05 Thread nagendra . k
Summary: amfd: correct loop variable initialization [#2404]
Review request for Trac Ticket(s): #2404
Peer Reviewer(s): Amf Dev
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 3657246fdbcf5062e46a733be2c3bd08cbaf53b0
Author: Nagendra Kumar
Date:   Wed, 05 Apr 2017 11:28:29 +0530

amfd: correct loop variable initialization [#2404]


Complete diffstat:
--
 src/amf/amfd/su.cc |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


Testing Commands:
-
Tested using trace.
Added 4 SI and did immlist on the SU.

Testing, Expected Results:
--
As per trace, now all the memory allocated as getting freed.

Conditions of Submission:
-
Ack

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.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: handle BAD_HANDLE return during config read [#2361]

2017-03-14 Thread nagendra . k
 osaf/services/saf/amf/amfd/imm.cc  |  18 +-
 osaf/services/saf/amf/amfd/role.cc |   4 ++--
 2 files changed, 15 insertions(+), 7 deletions(-)


If Immnd is killed, Amfd re-initializes with imm and re-reads configuration.
During configuration read if Immnd is again killed, Amfd exits.
The fix is to re-initialize if configuration reading fails.
Also, the fix re-initializes Om handles in case it is stale.

diff --git a/osaf/services/saf/amf/amfd/imm.cc 
b/osaf/services/saf/amf/amfd/imm.cc
--- a/osaf/services/saf/amf/amfd/imm.cc
+++ b/osaf/services/saf/amf/amfd/imm.cc
@@ -1663,7 +1663,7 @@ done:
if (rc == NCSCC_RC_SUCCESS)
TRACE("AMF Configuration successfully read from IMM");
else
-   LOG_ER("Failed to read configuration, AMF will not start");
+   LOG_WA("Failed to read configuration.");
 
TRACE_LEAVE2("%u", rc);
return rc;
@@ -1964,11 +1964,19 @@ static void *avd_imm_reinit_bg_thread(vo
osaf_mutex_unlock_ordie(_reinit_mutex);
exit(EXIT_FAILURE);
}
-
+   /* Lets re-initialize Om interface also. */
+   (void) immutil_saImmOmFinalize(cb->immOmHandle);
+   if ((rc = immutil_saImmOmInitialize(>immOmHandle, 
nullptr, )) != SA_AIS_OK) {
+   LOG_ER("saImmOmInitialize failed %u", rc);
+   continue;
+   }
if (avd_imm_config_get() != NCSCC_RC_SUCCESS) {
-   LOG_ER("avd_imm_config_get FAILED");
-   osaf_mutex_unlock_ordie(_reinit_mutex);
-   exit(EXIT_FAILURE);
+   /* This can come when Immnd is killed again 
during
+  config read and reading the config returned 
BAD_HANDLE.
+  In other return types also, it is good to 
retry.
+  In normal situations, retry will help. */
+   LOG_WA("avd_imm_config_get FAILED");
+   continue;
}
}
break;
diff --git a/osaf/services/saf/amf/amfd/role.cc 
b/osaf/services/saf/amf/amfd/role.cc
--- a/osaf/services/saf/amf/amfd/role.cc
+++ b/osaf/services/saf/amf/amfd/role.cc
@@ -270,7 +270,7 @@ uint32_t avd_active_role_initialization(
 }
 
if (avd_imm_config_get() != NCSCC_RC_SUCCESS) {
-   LOG_ER("avd_imm_config_get FAILED");
+   LOG_ER("avd_imm_config_get FAILED, AMF will not start.");
goto done;
}
 
@@ -304,7 +304,7 @@ uint32_t avd_standby_role_initialization
 }
 
if (avd_imm_config_get() != NCSCC_RC_SUCCESS) {
-   LOG_ER("avd_imm_config_get FAILED");
+   LOG_ER("avd_imm_config_get FAILED, AMF will not start.");
goto done;
}
 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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: handle BAD_HANDLE return during config read [#2361]

2017-03-14 Thread nagendra . k
Summary: amfd: handle BAD_HANDLE return during config read [#2361]
Review request for Trac Ticket(s): #2361
Peer Reviewer(s): Amf Dev
Pull request to: <>
Affected branch(es): All
Development branch: opensaf-5.1.x


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 de01cc39a7252dd01ddd572731f95776742082a1
Author: Nagendra Kumar
Date:   Tue, 14 Mar 2017 15:20:07 +0530

amfd: handle BAD_HANDLE return during config read [#2361] If Immnd is
killed, Amfd re-initializes with imm and re-reads configuration. During
configuration read if Immnd is again killed, Amfd exits. The fix is to 
re-
initialize if configuration reading fails. Also, the fix re-initializes 
Om
handles in case it is stale.


Complete diffstat:
--
 osaf/services/saf/amf/amfd/imm.cc  |  18 +-
 osaf/services/saf/amf/amfd/role.cc |   4 ++--
 2 files changed, 15 insertions(+), 7 deletions(-)


Testing Commands:
-
As per ticket description dated: 14 March 2017.

Testing, Expected Results:
--
Amfd should re-initialize itself.

Conditions of Submission:
-
Ack.

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.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 2 of 3] amfnd: Fix all Cppcheck 1.77 issues [#2341]

2017-03-08 Thread nagendra . k
 src/amf/amfnd/amfnd.cc   |  15 +--
 src/amf/amfnd/cbq.cc |   9 +++--
 src/amf/amfnd/chc.cc |  29 +++--
 src/amf/amfnd/clc.cc |  35 +--
 src/amf/amfnd/comp.cc|   8 +++-
 src/amf/amfnd/compdb.cc  |  14 +++---
 src/amf/amfnd/cpm.cc |  13 +
 src/amf/amfnd/di.cc  |  35 +--
 src/amf/amfnd/err.cc |  35 ++-
 src/amf/amfnd/evt.cc |   3 +--
 src/amf/amfnd/hcdb.cc|   7 +--
 src/amf/amfnd/imm.cc |   5 ++---
 src/amf/amfnd/main.cc|   8 +++-
 src/amf/amfnd/mds.cc |  20 +++-
 src/amf/amfnd/pg.cc  |  33 +++--
 src/amf/amfnd/proxy.cc   |   6 ++
 src/amf/amfnd/proxydb.cc |  17 +
 src/amf/amfnd/sidb.cc|   3 +--
 src/amf/amfnd/su.cc  |   3 +--
 src/amf/amfnd/sudb.cc|   5 ++---
 src/amf/amfnd/susm.cc|  19 +--
 src/amf/amfnd/util.cc|   2 +-
 22 files changed, 136 insertions(+), 188 deletions(-)


[staging/src/amf/amfnd/amfnd.cc:58] -> [staging/src/amf/amfnd/amfnd.cc:63]: 
(style) Variable 'del_cbk' is reassigned a value before the old one has been 
used.
[staging/src/amf/amfnd/amfnd.cc:59] -> [staging/src/amf/amfnd/amfnd.cc:65]: 
(style) Variable 'o_comp' is reassigned a value before the old one has been 
used.
[staging/src/amf/amfnd/amfnd.cc:191] -> [staging/src/amf/amfnd/amfnd.cc:199]: 
(style) Variable 'o_comp' is reassigned a value before the old one has been 
used.
[staging/src/amf/amfnd/amfnd.cc:249] -> [staging/src/amf/amfnd/amfnd.cc:250]: 
(style) Variable 'res' is reassigned a value before the old one has been used.
[staging/src/amf/amfnd/cbq.cc:441] -> [staging/src/amf/amfnd/cbq.cc:442]: 
(style) Variable 'temp_csi' is reassigned a value before the old one has been 
used.
[staging/src/amf/amfnd/cbq.cc:734] -> [staging/src/amf/amfnd/cbq.cc:748]: 
(style) Variable 'rc' is reassigned a value before the old one has been used.
[staging/src/amf/amfnd/cbq.cc:1132] -> [staging/src/amf/amfnd/cbq.cc:1133]: 
(style) Variable 'temp_csi' is reassigned a value before the old one has been 
used.
[staging/src/amf/amfnd/chc.cc:842]: (style) The scope of the variable 'cbk_rec' 
can be reduced.
[staging/src/amf/amfnd/clc.cc:610] -> [staging/src/amf/amfnd/clc.cc:616]: 
(style) Variable 'clc_evt' is reassigned a value before the old one has been 
used.
[staging/src/amf/amfnd/clc.cc:1706] -> [staging/src/amf/amfnd/clc.cc:1710]: 
(style) Variable 'rc' is reassigned a value before the old one has been used.
[staging/src/amf/amfnd/clc.cc:1747] -> [staging/src/amf/amfnd/clc.cc:1751]: 
(style) Variable 'rc' is reassigned a value before the old one has been used.
[staging/src/amf/amfnd/clc.cc:1949] -> [staging/src/amf/amfnd/clc.cc:1953]: 
(style) Variable 'rc' is reassigned a value before the old one has been used.
[staging/src/amf/amfnd/clc.cc:2368] -> [staging/src/amf/amfnd/clc.cc:2374]: 
(style) Variable 'csi' is reassigned a value before the old one has been used.
[staging/src/amf/amfnd/clc.cc:3050] -> [staging/src/amf/amfnd/clc.cc:3051]: 
(style) Variable 'tmp' is reassigned a value before the old one has been used.
[staging/src/amf/amfnd/clc.cc:3170] -> [staging/src/amf/amfnd/clc.cc:3179]: 
(style) Variable 'rc' is reassigned a value before the old one has been used.
[staging/src/amf/amfnd/clc.cc:1354]: (style) The scope of the variable 
'curr_rec' can be reduced.
[staging/src/amf/amfnd/clc.cc:1382]: (style) The scope of the variable 
'curr_rec' can be reduced.
[staging/src/amf/amfnd/clc.cc:3040]: (style) The scope of the variable 'i' can 
be reduced.
[staging/src/amf/amfnd/comp.cc:2557] -> [staging/src/amf/amfnd/comp.cc:2561]: 
(warning) Either the condition 'if(csi&_AVND_COMP_IS_ALL_CSI(comp))' is 
redundant or there is possible null pointer dereference: csi.
[staging/src/amf/amfnd/comp.cc:2237] -> [staging/src/amf/amfnd/comp.cc:2250]: 
(style) Variable 'rc' is reassigned a value before the old one has been used.
[staging/src/amf/amfnd/comp.cc:2962] -> [staging/src/amf/amfnd/comp.cc:2972]: 
(style) Variable 'rc' is reassigned a value before the old one has been used.
[staging/src/amf/amfnd/compdb.cc:485]: (warning) Comparison of a boolean 
expression with an integer.
[staging/src/amf/amfnd/compdb.cc:486]: (warning) Comparison of a boolean 
expression with an integer.
[staging/src/amf/amfnd/compdb.cc:485]: (warning) Comparison of a boolean value 
using relational operator (<, >, <= or >=).
[staging/src/amf/amfnd/compdb.cc:732] -> [staging/src/amf/amfnd/compdb.cc:734]: 
(warning) Either the condition '!compt' is redundant or there is possible null 
pointer dereference: compt.
[staging/src/amf/amfnd/compdb.cc:718] -> [staging/src/amf/amfnd/compdb.cc:721]: 
(style) Variable 'rc' is reassigned a value before the old one has been used.
[staging/src/amf/amfnd/compdb.cc:1378]: (style) The scope of the variable 
'env_counter' can 

[devel] [PATCH 1 of 3] amfd: Fix all Cppcheck 1.77 issues [#2341]

2017-03-08 Thread nagendra . k
 src/amf/amfd/app.cc|   3 +-
 src/amf/amfd/apptype.cc|   9 +
 src/amf/amfd/chkop.cc  |   3 +-
 src/amf/amfd/ckpt_dec.cc   |  15 +++
 src/amf/amfd/ckpt_edu.cc   |   3 +-
 src/amf/amfd/ckpt_enc.cc   |  60 ---
 src/amf/amfd/clm.cc|   5 +-
 src/amf/amfd/cluster.cc|  16 +++-
 src/amf/amfd/comp.cc   |  11 ++---
 src/amf/amfd/compcstype.cc |   7 +--
 src/amf/amfd/comptype.cc   |   3 +-
 src/amf/amfd/csi.cc|  23 ---
 src/amf/amfd/csiattr.cc|   9 +---
 src/amf/amfd/ctcstype.cc   |  10 +
 src/amf/amfd/dmsg.cc   |   4 +-
 src/amf/amfd/hlttype.cc|   3 +-
 src/amf/amfd/imm.cc|  49 ++---
 src/amf/amfd/main.cc   |  19 ++---
 src/amf/amfd/mds.cc|   4 +-
 src/amf/amfd/ndfsm.cc  |  35 +++---
 src/amf/amfd/ndproc.cc |  15 ++-
 src/amf/amfd/node.cc   |  24 ---
 src/amf/amfd/nodegroup.cc  |  10 ++---
 src/amf/amfd/role.cc   |  42 -
 src/amf/amfd/sg.cc |  23 ++-
 src/amf/amfd/sg_2n_fsm.cc  |  10 ++--
 src/amf/amfd/sg_nored_fsm.cc   |   3 +-
 src/amf/amfd/sg_npm_fsm.cc |  33 ++--
 src/amf/amfd/sg_nway_fsm.cc|  39 +++-
 src/amf/amfd/sg_nwayact_fsm.cc |   5 +-
 src/amf/amfd/sgproc.cc |  16 ++-
 src/amf/amfd/sgtype.cc |   3 +-
 src/amf/amfd/si.cc |  24 
 src/amf/amfd/si_dep.cc |  79 ++---
 src/amf/amfd/siass.cc  |  18 +++-
 src/amf/amfd/sirankedsu.cc |  17 +++-
 src/amf/amfd/su.cc |   8 +--
 src/amf/amfd/sutype.cc |   6 ---
 src/amf/amfd/util.cc   |  69 +--
 39 files changed, 260 insertions(+), 475 deletions(-)


[staging/src/amf/amfd/app.cc:285]: (style) The scope of the variable 'i' can be 
reduced.
[staging/src/amf/amfd/apptype.cc:137]: (style) Condition 'rc!=0' is always false
[staging/src/amf/amfd/apptype.cc:69]: (style) The scope of the variable 
'sg_type' can be reduced.
[staging/src/amf/amfd/chkop.cc:1297] -> [staging/src/amf/amfd/chkop.cc:1302]: 
(style) Variable 'uba' is reassigned a value before the old one has been used.
[staging/src/amf/amfd/ckpt_dec.cc:374] -> 
[staging/src/amf/amfd/ckpt_dec.cc:382]: (style) Variable 'status' is reassigned 
a value before the old one has been used.
[staging/src/amf/amfd/ckpt_dec.cc:573] -> 
[staging/src/amf/amfd/ckpt_dec.cc:577]: (style) Variable 'status' is reassigned 
a value before the old one has been used.
[staging/src/amf/amfd/ckpt_dec.cc:1109]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/ckpt_edu.cc:51] -> [staging/src/amf/amfd/ckpt_edu.cc:56]: 
(style) Variable 'rc' is reassigned a value before the old one has been used.
[staging/src/amf/amfd/ckpt_enc.cc:2281] -> 
[staging/src/amf/amfd/ckpt_enc.cc:2288]: (style) Variable 'status' is 
reassigned a value before the old one has been used.
[staging/src/amf/amfd/ckpt_enc.cc:2314] -> 
[staging/src/amf/amfd/ckpt_enc.cc:2322]: (style) Variable 'status' is 
reassigned a value before the old one has been used.
[staging/src/amf/amfd/ckpt_enc.cc:1951]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/ckpt_enc.cc:1982]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/ckpt_enc.cc:2015]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/ckpt_enc.cc:2044]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/ckpt_enc.cc:2076]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/ckpt_enc.cc:2111]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/ckpt_enc.cc:2151]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/ckpt_enc.cc:2176]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/ckpt_enc.cc:2216]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/ckpt_enc.cc:2252]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/ckpt_enc.cc:2470]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/clm.cc:344]: (performance) Prefer prefix ++/-- operators 
for non-primitive types.
[staging/src/amf/amfd/cluster.cc:82]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/cluster.cc:95]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/cluster.cc:116]: (performance) Prefer prefix ++/-- 
operators for non-primitive types.
[staging/src/amf/amfd/comp.cc:1270] -> 

[devel] [PATCH 0 of 1] Review Request for amfd: handle TIMEOUT for avd_imm_applier_set [#2338]

2017-03-08 Thread nagendra . k
Summary: amfd: handle TIMEOUT for avd_imm_applier_set [#2338]
Review request for Trac Ticket(s): #2338
Peer Reviewer(s): Amf Dev
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 b461f589dfcde95911f0b04881c5e518278f2b55
Author: Nagendra Kumar
Date:   Wed, 08 Mar 2017 13:12:19 +0530

amfd: handle TIMEOUT for avd_imm_applier_set [#2338]


Complete diffstat:
--
 src/amf/amfd/role.cc |  22 --
 src/amf/amfd/role.h  |   2 +-
 2 files changed, 17 insertions(+), 7 deletions(-)


Testing Commands:
-
1. To reproduce it, do the following changesi at SC-1:
diff --git a/src/amf/amfd/imm.cc b/src/amf/amfd/imm.cc
--- a/src/amf/amfd/imm.cc
+++ b/src/amf/amfd/imm.cc
@@ -1495,6 +1495,9 @@ SaAisErrorT avd_imm_applier_set(void)
  LOG_ER("Impl Set Failed for %s, returned %d",   
avd_class_names[i], rc);
  break;
  }
+ LOG_ER("1. Impl Set for %s  ", 
avd_class_names[i]);
+ sleep (1);
+ LOG_ER("2. Impl Set for %s  ", 
avd_class_names[i]);

2. Start SC-1 as Act and SC-2 as Standby.
   Now perform si swap of controllers and when logs of "Impl Set Failed for"
   starts comming on Quisced node(SC-1), kill immd on new Act node(SC-2). SC-2 
will reboot.
3. Amfd (SC-1) will hang in avd_imm_applier_set for 10 sec and timeout.

Testing, Expected Results:
--
After step 3, Amfd on SC-1 is declaring itself Act and when
SC-2 comes up after reboot, then it joins as Standby.

Conditions of Submission:
-
Ack

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.


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and 

[devel] [PATCH 1 of 1] amfd: handle TIMEOUT for avd_imm_applier_set [#2338]

2017-03-08 Thread nagendra . k
 src/amf/amfd/role.cc |  22 --
 src/amf/amfd/role.h  |   2 +-
 2 files changed, 17 insertions(+), 7 deletions(-)


diff --git a/src/amf/amfd/role.cc b/src/amf/amfd/role.cc
--- a/src/amf/amfd/role.cc
+++ b/src/amf/amfd/role.cc
@@ -130,7 +130,7 @@ void avd_role_change_evh(AVD_CL_CB *cb, 
(role == SA_AMF_HA_ACTIVE) && (cb->avail_state_avd == 
SA_AMF_HA_STANDBY)) {
if (true == cb->swap_switch ) {
/* swap resulted Switch  standby -> Active */
-   amfd_switch_stdby_actv(cb);
+   amfd_switch_stdby_actv(cb, true);
status = NCSCC_RC_SUCCESS;
goto done;
}
@@ -803,6 +803,12 @@ try_again:
   failed and amf reinitializes imm interface and
   set applier in avd_imm_reinit_bg_thread. Imm may
   return ERR_EXIST or INVALID_PARAM. */
+   TRACE("ERR_EXIST or INVALID_PARAM");
+   } else if (rc == SA_AIS_ERR_TIMEOUT) {
+   /* Let it proceed as there may be a case of Immd not
+  reachable i.e. node might have gone down during
+  switchover. */
+   TRACE("SA_AIS_ERR_TIMEOUT");
} else
osafassert(0);
} else
@@ -1147,6 +1153,7 @@ uint32_t amfd_switch_qsd_stdby(AVD_CL_CB
  *   change from standby to active in liue of SI SWAP Action
  * 
  * Input: cb - AVD control block pointer.
+ * Input: switch_flag - Whether switchover passed or failed.
  *
  * Returns: NCSCC_RC_SUCCESS/NCSCC_RC_FAILURE.
  *
@@ -1155,14 +1162,15 @@ uint32_t amfd_switch_qsd_stdby(AVD_CL_CB
  * 
  **/
 
-uint32_t amfd_switch_stdby_actv(AVD_CL_CB *cb)
+uint32_t amfd_switch_stdby_actv(AVD_CL_CB *cb, bool switchover_flag)
 {
uint32_t status = NCSCC_RC_SUCCESS;
SaAisErrorT rc;

TRACE_ENTER();
 
-   LOG_NO("Switching StandBy --> Active State");
+   if (switchover_flag)
+   LOG_NO("Switching StandBy --> Active State");
 
/*
 * Check whether Standby is in sync with Active. If yes then
@@ -1282,8 +1290,10 @@ uint32_t amfd_switch_stdby_actv(AVD_CL_C
}
}
 
-   LOG_NO("Controller switch over done");
-   saflog(LOG_NOTICE, amfSvcUsrName, "Controller switch over done at %x", 
cb->node_id_avd);
+   if (switchover_flag) {
+   LOG_NO("Controller switch over done");
+   saflog(LOG_NOTICE, amfSvcUsrName, "Controller switch over done 
at %x", cb->node_id_avd);
+   }
 
TRACE_LEAVE();
return NCSCC_RC_SUCCESS;
@@ -1311,7 +1321,7 @@ uint32_t amfd_switch_qsd_actv (AVD_CL_CB
if (NCSCC_RC_SUCCESS != avd_rde_set_role(SA_AMF_HA_ACTIVE)) {
LOG_ER("rde role change failed from qsd -> actv");
}
-   return amfd_switch_stdby_actv(cb);
+   return amfd_switch_stdby_actv(cb, false);
 }
 
 
diff --git a/src/amf/amfd/role.h b/src/amf/amfd/role.h
--- a/src/amf/amfd/role.h
+++ b/src/amf/amfd/role.h
@@ -31,7 +31,7 @@ extern uint32_t avd_d2d_chg_role_rsp(AVD
 extern uint32_t avd_d2d_chg_role_req(AVD_CL_CB *cb, AVD_ROLE_CHG_CAUSE_T 
cause, SaAmfHAStateT role);
 
 extern uint32_t amfd_switch_qsd_stdby(AVD_CL_CB *cb);
-extern uint32_t amfd_switch_stdby_actv(AVD_CL_CB *cb);
+extern uint32_t amfd_switch_stdby_actv(AVD_CL_CB *cb, bool);
 extern uint32_t amfd_switch_qsd_actv(AVD_CL_CB *cb);
 extern uint32_t amfd_switch_actv_qsd(AVD_CL_CB *cb);
 extern uint32_t initialize_for_assignment(cl_cb_tag* cb,

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
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: avoid null pointer access [#2213]

2017-03-06 Thread nagendra . k
Summary: amfnd: avoid null pointer access [#2213]
Review request for Trac Ticket(s): #2213
Peer Reviewer(s): Amf Dev
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 0a81abe9cd0056c937eba0f9edb14a42200ea792
Author: Nagendra Kumar
Date:   Tue, 07 Mar 2017 11:58:24 +0530

amfnd: avoid null pointer access [#2213]


Complete diffstat:
--
 src/amf/amfnd/comp.cc |  4 
 1 files changed, 4 insertions(+), 0 deletions(-)


Testing Commands:
-
Compiled.

Testing, Expected Results:
--
Compiled.

Conditions of Submission:
-
Ack

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.


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfnd: avoid null pointer access [#2213]

2017-03-06 Thread nagendra . k
 src/amf/amfnd/comp.cc |  4 
 1 files changed, 4 insertions(+), 0 deletions(-)


diff --git a/src/amf/amfnd/comp.cc b/src/amf/amfnd/comp.cc
--- a/src/amf/amfnd/comp.cc
+++ b/src/amf/amfnd/comp.cc
@@ -2650,6 +2650,10 @@ void avnd_comp_cmplete_all_csi_rec(AVND_
/* generate csi-remove-done event... csi may be 
deleted */
(void)avnd_comp_csi_remove_done(cb, comp, curr);
 
+   /* Avoid nullptr access. */
+   if (curr == nullptr)
+   break;
+
if (0 == m_AVND_COMPDB_REC_CSI_GET(*comp, 
curr->name.c_str())) {
curr =
(prv) ?

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
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: update counters during switchover [#2345]

2017-03-06 Thread nagendra . k
Summary: amfnd: update counters during switchover [#2345]
Review request for Trac Ticket(s): #2345
Peer Reviewer(s): Amf Dev
Pull request to: <>
Affected branch(es): 5.1 and 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 3268649ae0f11819489da0d3ba7258f30773ccef
Author: Nagendra Kumar
Date:   Mon, 06 Mar 2017 13:15:11 +0530

amfnd: update counters during switchover [#2345] In some cases, Amfnd is
getting role change event before AVD up message, which is rare. In
avnd_evt_avd_role_change_evh, if AVD flag is not marked up, then it is 
not
updating the counters and returning from there. This creates a mismatch 
into
counters of messages exchanged among amfd and amfnd. This leads to Amfnd
reboots the node. Since, avnd_evt_avd_role_change_evh is not a 
significant
message for Amfnd, so we can update the messages counters first and 
return
from there.


Complete diffstat:
--
 src/amf/amfnd/di.cc |  13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)


Testing Commands:
-
As per ticket.

Testing, Expected Results:
--
No crash of Amfnd.

Conditions of Submission:
-
Ack

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.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfnd: update counters during switchover [#2345]

2017-03-06 Thread nagendra . k
 src/amf/amfnd/di.cc |  13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)


In some cases, Amfnd is getting role change event
before AVD up message, which is rare.
In avnd_evt_avd_role_change_evh, if AVD flag is
not marked up, then it is not updating the counters and
returning from there. This creates a mismatch into counters of messages
exchanged among amfd and amfnd. This leads to Amfnd reboots the node.
Since, avnd_evt_avd_role_change_evh is not a significant message for
Amfnd, so we can update the messages counters first and return from there.

diff --git a/src/amf/amfnd/di.cc b/src/amf/amfnd/di.cc
--- a/src/amf/amfnd/di.cc
+++ b/src/amf/amfnd/di.cc
@@ -1510,12 +1510,7 @@ uint32_t avnd_evt_avd_role_change_evh(AV
 
TRACE_ENTER();
 
-   /* dont process unless AvD is up */
-   if (!m_AVND_CB_IS_AVD_UP(cb)){
-   LOG_IN("AVD is not up yet");
-   return NCSCC_RC_FAILURE;
-   }
-
+   /* Correct the counters first. */
info = >info.avd->msg_info.d2n_role_change_info;
 
TRACE("MsgId: %u,NodeId:%u, role rcvd:%u role present:%u",\
@@ -1524,6 +1519,12 @@ uint32_t avnd_evt_avd_role_change_evh(AV
avnd_msgid_assert(info->msg_id);
cb->rcv_msg_id = info->msg_id;
 
+   /* dont process unless AvD is up */
+   if (!m_AVND_CB_IS_AVD_UP(cb)){
+   LOG_IN("AVD is not up yet");
+   return NCSCC_RC_FAILURE;
+   }
+
prev_ha_state = cb->avail_state_avnd;
 
/* Ignore the duplicate roles. */

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
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: fix null ptr accessing issue [#2322]

2017-02-23 Thread nagendra . k
Summary: amfd: fix null ptr accessing issue [#2322]
Review request for Trac Ticket(s): #2322
Peer Reviewer(s): Amf Dev 
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 aeaba2237e4b217ee2c2284c08bf799b1b8e6463
Author: Nagendra Kumar
Date:   Thu, 23 Feb 2017 17:15:04 +0530

amfd: fix null ptr accessing issue [#2322]


Complete diffstat:
--
 src/amf/amfd/sutcomptype.cc |  12 +---
 1 files changed, 5 insertions(+), 7 deletions(-)


Testing Commands:
-
Please check the ticket.

Testing, Expected Results:
--
Amfd shouldnot crash.

Conditions of Submission:
-
Ack

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.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: fix null ptr accessing issue [#2322]

2017-02-23 Thread nagendra . k
 src/amf/amfd/sutcomptype.cc |  12 +---
 1 files changed, 5 insertions(+), 7 deletions(-)


diff --git a/src/amf/amfd/sutcomptype.cc b/src/amf/amfd/sutcomptype.cc
--- a/src/amf/amfd/sutcomptype.cc
+++ b/src/amf/amfd/sutcomptype.cc
@@ -114,7 +114,6 @@ SaAisErrorT avd_sutcomptype_config_get(c
 static SaAisErrorT sutcomptype_ccb_completed_cb(CcbUtilOperationData_t *opdata)
 {
SaAisErrorT rc = SA_AIS_ERR_BAD_OPERATION;
-   AVD_SUTCOMP_TYPE *sutcomptype = nullptr;
 
TRACE_ENTER2("CCB ID %llu, '%s'", opdata->ccbId, 
osaf_extended_name_borrow(>objectName));
 
@@ -127,11 +126,7 @@ static SaAisErrorT sutcomptype_ccb_compl
report_ccb_validation_error(opdata, "Modification of 
SaAmfSUType not supported");
break;
case CCBUTIL_DELETE:
-   sutcomptype = 
sutcomptype_db->find(Amf::to_string(>objectName));
-   if (sutcomptype->curr_num_components == 0) {
-   rc = SA_AIS_OK;
-   opdata->userData = sutcomptype; /* Save for later use 
in apply */
-   }
+   rc = SA_AIS_OK;
break;
default:
osafassert(0);
@@ -154,7 +149,10 @@ static void sutcomptype_ccb_apply_cb(Ccb
sutcomptype_db_add(sutcomptype);
break;
case CCBUTIL_DELETE:
-   
sutcomptype_delete(static_cast(opdata->userData));
+   sutcomptype = 
sutcomptype_db->find(Amf::to_string(>objectName));
+   if (sutcomptype != nullptr) {
+   sutcomptype_delete(sutcomptype);
+   }
break;
default:
osafassert(0);

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
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: change LOG_ER to LOG_NO [#1749]

2017-02-09 Thread nagendra . k
Summary: amfd: change LOG_ER to LOG_NO [#1749]
Review request for Trac Ticket(s): #1749
Peer Reviewer(s): Amf Dev 
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 02f32ef64b98294a87c06ff48cf013cc2333b89e
Author: Nagendra Kumar
Date:   Thu, 09 Feb 2017 15:51:38 +0530

amfd: change LOG_ER to LOG_NO [#1749]


Complete diffstat:
--
 src/amf/amfd/comp.cc  |  2 +-
 src/amf/amfd/imm.cc   |  2 +-
 src/amf/amfd/nodegroup.cc |  6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)


Testing Commands:
-
Compiled

Testing, Expected Results:
--
Compiled

Conditions of Submission:
-
Ack from Amf Dev

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.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: change LOG_ER to LOG_NO [#1749]

2017-02-09 Thread nagendra . k
 src/amf/amfd/comp.cc  |  2 +-
 src/amf/amfd/imm.cc   |  2 +-
 src/amf/amfd/nodegroup.cc |  6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)


diff --git a/src/amf/amfd/comp.cc b/src/amf/amfd/comp.cc
--- a/src/amf/amfd/comp.cc
+++ b/src/amf/amfd/comp.cc
@@ -759,7 +759,7 @@ SaAisErrorT avd_comp_config_get(const st
 
/* If there are no component in the SU, we treat it as invalid 
configuration. */
if (0 == num_of_comp_in_su) {
-   LOG_ER("There is no component configured for SU '%s'", 
su_name.c_str());
+   LOG_NO("There is no component configured for SU '%s'", 
su_name.c_str());
goto done2;
}
 
diff --git a/src/amf/amfd/imm.cc b/src/amf/amfd/imm.cc
--- a/src/amf/amfd/imm.cc
+++ b/src/amf/amfd/imm.cc
@@ -813,7 +813,7 @@ static void admin_operation_cb(SaImmOiHa
admin_op_callback[type](immoi_handle, invocation, 
obj_name, op_id, params);
}
} else {
-   LOG_ER("Admin operation not supported for %s (%u)", 
object_name.c_str(), type);
+   LOG_NO("Admin operation not supported for %s (%u)", 
object_name.c_str(), type);
report_admin_op_error(immoi_handle, invocation, 
SA_AIS_ERR_INVALID_PARAM, nullptr,
"Admin operation not supported for %s (%u)", 
object_name.c_str(), type);
}
diff --git a/src/amf/amfd/nodegroup.cc b/src/amf/amfd/nodegroup.cc
--- a/src/amf/amfd/nodegroup.cc
+++ b/src/amf/amfd/nodegroup.cc
@@ -109,14 +109,14 @@ static int is_config_valid(const std::st
}
 
if (attr->attrValuesNumber != tmp_ng->number_nodes()) {
-   LOG_ER("Duplicate nodes in saAmfNGNodeList of 
'%s'",tmp_ng->name.c_str());
+   LOG_NO("Duplicate nodes in saAmfNGNodeList of 
'%s'",tmp_ng->name.c_str());
delete tmp_ng;
TRACE_LEAVE();
return 0;
}
//Check if admin state is valid or not.
if (!avd_admin_state_is_valid(tmp_ng->saAmfNGAdminState, opdata)) {
-   LOG_ER("Incorrect saAmfNGAdminState:'%u' for 
'%s'",tmp_ng->saAmfNGAdminState,
+   LOG_NO("Incorrect saAmfNGAdminState:'%u' for 
'%s'",tmp_ng->saAmfNGAdminState,
tmp_ng->name.c_str());
delete tmp_ng;
TRACE_LEAVE();
@@ -169,7 +169,7 @@ static AVD_AMF_NG *ng_create(const std::
}
}
else {
-   LOG_ER("Node groups must contain at least one node");
+   LOG_NO("Node groups must contain at least one node");
goto done;
}
if (immutil_getAttr(const_cast("saAmfNGAdminState"),

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
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: return TRY_AGAIN on rollback of shutdown admin op [#2133]

2017-02-06 Thread nagendra . k
Summary: amfd: return TRY_AGAIN on rollback of shutdown admin op [#2133]
Review request for Trac Ticket(s): #2133 
Peer Reviewer(s): hans.nordeb...@ericsson.com, praveen.malv...@oracle.com, 
minh.c...@dektech.com.au, gary@dektech.com.au
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 af4a16ea73c02aa5cb92f003559a9282582dfa27
Author: Nagendra Kumar
Date:   Tue, 07 Feb 2017 11:36:23 +0530

amfd: return TRY_AGAIN on rollback of shutdown admin op [#2133] When
shutdown operation on SI is issued and if there are some faults 
(component
failover, SU failover or node failover) on components on SU getting
quiescing csi cbk, then in the following situation TRY_AGAIN is 
returned and
admin state is rolled back to unlock: For SI having only one SUSI:
Without SI Dep : a.) in comp fo. For SI having two SUSI: Without SI Dep 
:
a.) in node fo, su fo, comp fo. With SI Dep : a.) node fo, su fo. In 
other
cases below, the admin state is marked locked : For SI having only one 
SUSI:
Without SI Dep : a.) node fo, su fo. With SI Dep : a.) node fo, su fo,
comp fo. For SI having two SUSI: With SI Dep : a.) Comp fo


Complete diffstat:
--
 src/amf/amfd/sg_2n_fsm.cc |  17 +
 src/amf/amfd/sgproc.cc|  13 ++---
 2 files changed, 27 insertions(+), 3 deletions(-)


Testing Commands:
-
A. Configure SI with only one SU Act on PL-3
--
Without SI Dep:
1. Configure comp failover and issue si shutdown, keep gdb in quiescing csi cbk 
and kill component.
Operation is reverted and admin state is Unlocked and return type is TRY_AGAIN.
2. Configure SU failover and issue si shutdown, keep gdb in quiescing csi cbk 
and kill component.
Operation succeeds and admin state of SI is locked and return type is OK.
3. Issue si shutdown, keep gdb in quiescing csi cbk and stop PL-3.
Operation succeeds and admin state of SI is locked and return type is OK.

With SI Dep: For all above steps, Operation succeeds and admin state of SI is 
locked and return type is OK.
--

B. Configure SI with one SU Act on PL-3 and another SU standby on SC-1.
--
Without SI Dep: Operation is reverted and admin state is Unlocked and return 
type is TRY_AGAIN. 

With SI Dep: For steps #2 and #3, Operation is reverted and admin state is 
Unlocked and return type is TRY_AGAIN.
 For step #1, Operation succeeds and admin state of SI is locked 
and return type is OK.


Testing, Expected Results:
--
As mentioned above.

Conditions of Submission:
-
Ack from 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 

[devel] [PATCH 1 of 1] amfd: return TRY_AGAIN on rollback of shutdown admin op [#2133]

2017-02-06 Thread nagendra . k
 src/amf/amfd/sg_2n_fsm.cc |  17 +
 src/amf/amfd/sgproc.cc|  13 ++---
 2 files changed, 27 insertions(+), 3 deletions(-)


When shutdown operation on SI is issued and if there are
some faults (component failover, SU failover or node failover) on
components on SU getting quiescing csi cbk, then in the following situation
TRY_AGAIN is returned and admin state is rolled back to unlock:
For SI having only one SUSI:
   Without SI Dep : a.) in comp fo
For SI having two SUSI:
   Without SI Dep : a.) in node fo, su fo, comp fo
   With SI Dep : a.) node fo, su fo
In other cases below, the admin state is marked locked :
For SI having only one SUSI:
   Without SI Dep : a.) node fo, su fo
   With SI Dep :a.) node fo, su fo, comp fo
For SI having two SUSI:
   With SI Dep : a.) Comp fo

diff --git a/src/amf/amfd/sg_2n_fsm.cc b/src/amf/amfd/sg_2n_fsm.cc
--- a/src/amf/amfd/sg_2n_fsm.cc
+++ b/src/amf/amfd/sg_2n_fsm.cc
@@ -1,6 +1,7 @@
 /*  -*- OpenSAF  -*-
  *
  * (C) Copyright 2008 The OpenSAF Foundation
+ * Copyright (C) 2017, Oracle and/or its affiliates. All rights reserved.
  *
  * This program is distributed in the hope that it will be useful, but
  * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
@@ -1050,9 +1051,17 @@ uint32_t SG_2N::su_fault_si_oper(AVD_SU 

su->sg_of_su->admin_si->set_admin_state(SA_AMF_ADMIN_LOCKED);
else

su->sg_of_su->admin_si->set_admin_state(SA_AMF_ADMIN_UNLOCKED);
+   AVD_SI *si_tmp = su->sg_of_su->admin_si;
m_AVD_CLEAR_SG_ADMIN_SI(cb, (su->sg_of_su));
avd_sg_su_oper_list_add(cb, su, false);
su->sg_of_su->set_fsm_state(AVD_SG_FSM_SU_OPER);
+   if ((si_tmp->invocation != 0) && 
(si_tmp->saAmfSIAdminState == SA_AMF_ADMIN_UNLOCKED)) {
+   TRACE("Admin operation fails on 
SI:'%s'", si_tmp->name.c_str());
+   
avd_saImmOiAdminOperationResult(avd_cb->immOiHandle,
+   si_tmp->invocation, 
SA_AIS_ERR_TRY_AGAIN);
+   si_tmp->invocation = 0;
+   }
+
} else {
/* The SU has standby assignments. Change the 
SI admin state to
 * unlock. Remove the SI from the SI admin 
pointer. 
@@ -3150,8 +3159,16 @@ void SG_2N::node_fail_si_oper(AVD_SU *su
}
 

su->sg_of_su->admin_si->set_admin_state(SA_AMF_ADMIN_UNLOCKED);
+   AVD_SI *si_tmp = su->sg_of_su->admin_si;
m_AVD_CLEAR_SG_ADMIN_SI(cb, (su->sg_of_su));
su->delete_all_susis();
+   if (si_tmp->invocation != 0) {
+   TRACE("Admin operation fails on 
SI:'%s'", si_tmp->name.c_str());
+   
avd_saImmOiAdminOperationResult(avd_cb->immOiHandle,
+   si_tmp->invocation, 
SA_AIS_ERR_TRY_AGAIN);
+   si_tmp->invocation = 0;
+   }
+
} /* if (s_susi != AVD_SU_SI_REL_NULL) */
else {

su->sg_of_su->admin_si->set_admin_state(SA_AMF_ADMIN_LOCKED);
diff --git a/src/amf/amfd/sgproc.cc b/src/amf/amfd/sgproc.cc
--- a/src/amf/amfd/sgproc.cc
+++ b/src/amf/amfd/sgproc.cc
@@ -1,6 +1,7 @@
 /*  -*- OpenSAF  -*-
  *
  * (C) Copyright 2008 The OpenSAF Foundation
+ * Copyright (C) 2017, Oracle and/or its affiliates. All rights reserved.
  *
  * This program is distributed in the hope that it will be useful, but
  * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
@@ -518,9 +519,15 @@ static uint32_t sg_su_failover_func(AVD_
 
/* Reply to IMM for admin operation on SI */
if (susi->si->invocation != 0) {
-   
avd_saImmOiAdminOperationResult(avd_cb->immOiHandle,
-   susi->si->invocation, 
SA_AIS_OK);
-   susi->si->invocation = 0;
+   if ((susi->su->sg_of_su->admin_si != nullptr) &&
+   
(susi->su->sg_of_su->admin_si->saAmfSIAdminState == SA_AMF_ADMIN_SHUTTING_DOWN) 
&&
+   
(susi->su->sg_of_su->sg_redundancy_model == SA_AMF_2N_REDUNDANCY_MODEL)) {
+   TRACE("Do nothing.");
+   } else {
+  

[devel] [PATCH 0 of 1] Review Request for amfnd: add cleanup command for proxy and proxied [#2186]

2016-11-17 Thread nagendra . k
Summary: amfnd: add cleanup command for proxy and proxied [#2186]
Review request for Trac Ticket(s): #2186
Peer Reviewer(s): Amf Dev
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 337c6dde5dfca14c8af4299a2a2598958bd1ea37
Author: Nagendra Kumar
Date:   Thu, 17 Nov 2016 13:41:09 +0530

amfnd: add cleanup command for proxy and proxied [#2186] When proxy and
proxied are in the same SU and if proxy fails and SU restart is 
escalated,
then proxied are not being cleaned up. Added cleanup commands for 
proxied
component if their proxy are not in healthy state. Also, during opensafd
stop, opensafd is not able to terminate the proxy. Added fix for this 
also.


Complete diffstat:
--
 osaf/services/saf/amf/amfnd/clc.cc  |  38 
++
 osaf/services/saf/amf/amfnd/susm.cc |  24 +++-
 2 files changed, 53 insertions(+), 9 deletions(-)


Testing Commands:
-
Please use proxy.c and proxy.xml for testing attached in the ticket.
Proxy.xml is having Su with 1 proxy component and two proxied components.
Configured saAmfSgtDefCompRestartMax as 1.

1. immcfg -f proxy.xml
2. amf-adm unlock-in safSu=1,safSg=2N,safApp=Proxy; amf-adm unlock 
safSu=1,safSg=2N,safApp=Proxy
3. pkill -9 proxy and again pkill -9 proxy to restart SU.
4. amf-adm unlock-in safSu=1,safSg=2N,safApp=Proxy; amf-adm unlock 
safSu=1,safSg=2N,safApp=Proxy
5. amf-adm lock  safSu=1,safSg=2N,safApp=Proxy 
6. amf-adm unlock  safSu=1,safSg=2N,safApp=Proxy 
7. amf-adm restart  safSu=1,safSg=2N,safApp=Proxy 

Testing, Expected Results:
--
All steps #4 to #7 worked fine.

Conditions of Submission:
-
Ack from Amf Dev

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.



[devel] [PATCH 1 of 1] amfnd: add cleanup command for proxy and proxied [#2186]

2016-11-17 Thread nagendra . k
 osaf/services/saf/amf/amfnd/clc.cc  |  38 +---
 osaf/services/saf/amf/amfnd/susm.cc |  24 ++-
 2 files changed, 53 insertions(+), 9 deletions(-)


When proxy and proxied are in the same SU and if proxy
fails and SU restart is escalated, then proxied are not being
cleaned up.
Added cleanup commands for proxied component if their proxy are not
in healthy state.
Also, during opensafd stop, opensafd is not able to terminate the proxy.
Added fix for this also.

diff --git a/osaf/services/saf/amf/amfnd/clc.cc 
b/osaf/services/saf/amf/amfnd/clc.cc
--- a/osaf/services/saf/amf/amfnd/clc.cc
+++ b/osaf/services/saf/amf/amfnd/clc.cc
@@ -2020,26 +2020,48 @@ uint32_t avnd_comp_clc_inst_clean_hdler(
 
if (m_AVND_COMP_TYPE_IS_PROXIED(comp)) {
avnd_comp_cbq_del(cb, comp, true);
-   /* call the cleanup callback */
-   rc = avnd_comp_cbk_send(cb, comp, AVSV_AMF_PXIED_COMP_CLEAN, 0, 
0);
+   /* Check whether
+  1. it is a case of SU restart escalation.
+  2. it is a case of proxy-proxied residing in the same SU.
+  3. the proxy of this component is in good state to accept 
the callback.*/
+
+   /* Check if the proxy and proxied components are in the same 
SUs. */
+   if ((m_AVND_SU_IS_RESTART(comp->su) && 
m_AVND_SU_IS_FAILED(comp->su)) && /* #1. */
+   ((comp->pxy_comp) && (comp->su == 
comp->pxy_comp->su)) && /* #2  */
+   (m_AVND_COMP_IS_FAILED(comp->pxy_comp))) { /* 
#3 */
+   /* If proxy is not in good shape, we can't issue 
callback, so issue cleanup
+  (assume it is local component). */
+   rc = avnd_comp_clc_cmd_execute(cb, comp, 
AVND_COMP_CLC_CMD_TYPE_CLEANUP);
+   } else {
+   /* call the cleanup callback */
+   rc = avnd_comp_cbk_send(cb, comp, 
AVSV_AMF_PXIED_COMP_CLEAN, 0, 0);
+   }
} else if (m_AVND_COMP_TYPE_IS_PROXY(comp) && comp->pxied_list.n_nodes) 
{
/* if there are still outstanding proxied components we can't 
terminate right now */
/* Check if the proxy and proxied components are in the same 
SUs. */
TRACE("Proxy has proxied components: %u", 
comp->pxied_list.n_nodes);
AVND_COMP_PXIED_REC *rec;
rec = (AVND_COMP_PXIED_REC 
*)m_NCS_DBLIST_FIND_FIRST(>pxied_list);
-while (rec) {
-if (comp->su == rec->pxied_comp->su)
+   while (rec) {
+   if (comp->su == rec->pxied_comp->su)
break;
-rec = (AVND_COMP_PXIED_REC 
*)m_NCS_DBLIST_FIND_NEXT(>comp_dll_node);
-}
+   rec = (AVND_COMP_PXIED_REC 
*)m_NCS_DBLIST_FIND_NEXT(>comp_dll_node);
+   }
if (rec == nullptr) {
TRACE("Proxy and proxied are not in the same SU.");
/* This means that proxy and proxied components are not 
in the same SU.
   That means that we can cleanup the component. */
rc = avnd_comp_clc_cmd_execute(cb, comp, 
AVND_COMP_CLC_CMD_TYPE_CLEANUP);
-   } else
-   return rc;
+   } else {
+   TRACE("Proxy and proxied are in the same SU.");
+   if (((m_AVND_SU_IS_RESTART(comp->su) && 
m_AVND_SU_IS_FAILED(comp->su)) &&
+   (m_AVND_COMP_IS_FAILED(comp))) 
||
+   (cb->term_state == 
AVND_TERM_STATE_OPENSAF_SHUTDOWN_STARTED)) {
+   /* If proxy is not in good shape, so issue 
cleanup. */
+   rc = avnd_comp_clc_cmd_execute(cb, comp, 
AVND_COMP_CLC_CMD_TYPE_CLEANUP);
+   } else
+   goto done;
+   }
} else {
if (m_AVND_SU_IS_RESTART(comp->su) && 
m_AVND_COMP_IS_RESTART_DIS(comp) &&
(comp->csi_list.n_nodes > 0) &&
diff --git a/osaf/services/saf/amf/amfnd/susm.cc 
b/osaf/services/saf/amf/amfnd/susm.cc
--- a/osaf/services/saf/amf/amfnd/susm.cc
+++ b/osaf/services/saf/amf/amfnd/susm.cc
@@ -2601,8 +2601,30 @@ uint32_t avnd_su_pres_inst_comprestart_h
if (NCSCC_RC_SUCCESS != rc)
goto done;
break;
+   } else {
+   /*
+  For a NPI comp in SU, component FSM is 
always triggered
+  at the time of assignments. If this 
component is
+  non-restartable then start 

[devel] [PATCH 1 of 1] amfnd: clean proxy if proxy and proxied are not in the same SU [#2169]

2016-11-08 Thread nagendra . k
 osaf/services/saf/amf/amfnd/clc.cc |  17 -
 1 files changed, 16 insertions(+), 1 deletions(-)


diff --git a/osaf/services/saf/amf/amfnd/clc.cc 
b/osaf/services/saf/amf/amfnd/clc.cc
--- a/osaf/services/saf/amf/amfnd/clc.cc
+++ b/osaf/services/saf/amf/amfnd/clc.cc
@@ -2024,7 +2024,22 @@ uint32_t avnd_comp_clc_inst_clean_hdler(
rc = avnd_comp_cbk_send(cb, comp, AVSV_AMF_PXIED_COMP_CLEAN, 0, 
0);
} else if (m_AVND_COMP_TYPE_IS_PROXY(comp) && comp->pxied_list.n_nodes) 
{
/* if there are still outstanding proxied components we can't 
terminate right now */
-   return rc;
+   /* Check if the proxy and proxied components are in the same 
SUs. */
+   TRACE("Proxy has proxied components: %u", 
comp->pxied_list.n_nodes);
+   AVND_COMP_PXIED_REC *rec;
+   rec = (AVND_COMP_PXIED_REC 
*)m_NCS_DBLIST_FIND_FIRST(>pxied_list);
+while (rec) {
+if (comp->su == rec->pxied_comp->su)
+   break;
+rec = (AVND_COMP_PXIED_REC 
*)m_NCS_DBLIST_FIND_NEXT(>comp_dll_node);
+}
+   if (rec == nullptr) {
+   TRACE("Proxy and proxied are not in the same SU.");
+   /* This means that proxy and proxied components are not 
in the same SU.
+  That means that we can cleanup the component. */
+   rc = avnd_comp_clc_cmd_execute(cb, comp, 
AVND_COMP_CLC_CMD_TYPE_CLEANUP);
+   } else
+   return rc;
} else {
if (m_AVND_SU_IS_RESTART(comp->su) && 
m_AVND_COMP_IS_RESTART_DIS(comp) &&
(comp->csi_list.n_nodes > 0) &&

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
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: clean proxy if proxy and proxied are not in the same SU [#2169]

2016-11-08 Thread nagendra . k
Summary: amfnd: clean proxy if proxy and proxied are not in the same SU [#2169]
Review request for Trac Ticket(s): #2169
Peer Reviewer(s): Amf Dev
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 13585f8f543960aed090d9344e6d640c9872551e
Author: Nagendra Kumar
Date:   Tue, 08 Nov 2016 13:57:12 +0530

amfnd: clean proxy if proxy and proxied are not in the same SU [#2169]


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


Testing Commands:
-
1. Use proxy demo available in samples/amf/proxy/.
2. Unlock proxy adn proxied using test.sh
3. Run the below commands to kill proxy component twice:
pkill -9 proxy
pkill -9 proxy

4. Lock SU1:
amf-adm  lock safSu=1,safSg=2N,safApp=Proxy

5. Unlock SU1:
amf-adm  unlock safSu=1,safSg=2N,safApp=Proxy

Testing, Expected Results:
--
After step #3, Su1 is restarted and re-assigned assignments.
After step #4, proxy SU assignments are removed and proxied components are 
moved into Orphan state.
After step #5, proxy gets assingments and proxied are moved into Instantiated 
state.

PM_SC-1:/home/nagu/views/staging/samples/amf/proxy # amf-state  siass
safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
safSISU=safSu=SC-1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
safSISU=safSu=1\,safSg=2N\,safApp=Proxy,safSi=1,safApp=Proxy
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)
safSISU=safSu=1\,safSg=2N\,safApp=Proxied,safSi=1,safApp=Proxied
saAmfSISUHAState=ACTIVE(1)
saAmfSISUHAReadinessState=READY_FOR_ASSIGNMENT(1)

PM_SC-1:/home/nagu/views/staging/samples/amf/proxy # immlist -a 
saAmfCompPresenceState safComp=1,safSu=1,safSg=2N,safApp=Proxied
saAmfCompPresenceState=3
PM_SC-1:/home/nagu/views/staging/samples/amf/proxy # immlist -a 
saAmfCompPresenceState safComp=2,safSu=1,safSg=2N,safApp=Proxied
saAmfCompPresenceState=3


Conditions of Submission:
-
Ack from Amf Dev

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 

[devel] [PATCH 1 of 1] amfa: return SA_AIS_ERR_VERSION from saAmfComponentUnregister [#171]

2016-11-07 Thread nagendra . k
 osaf/libs/agents/saf/amfa/amf_agent.cc |  8 
 1 files changed, 8 insertions(+), 0 deletions(-)


diff --git a/osaf/libs/agents/saf/amfa/amf_agent.cc 
b/osaf/libs/agents/saf/amfa/amf_agent.cc
--- a/osaf/libs/agents/saf/amfa/amf_agent.cc
+++ b/osaf/libs/agents/saf/amfa/amf_agent.cc
@@ -617,8 +617,16 @@ SaAisErrorT AmfAgent::ComponentUnregiste
 rc = SA_AIS_ERR_LIBRARY;
 goto done;
   }
+
   /* acquire cb read lock */
   m_NCS_LOCK(>lock, NCS_LOCK_READ);
+  /* Version is previously set in in initialize function */
+  if(ava_B4_ver_used(cb)) {
+ TRACE_2("Invalid AMF version, B 4.1");
+ rc = SA_AIS_ERR_VERSION;
+ goto done;
+  }
+
   /* retrieve hdl rec */
   if ( !(hdl_rec = (AVA_HDL_REC *)ncshm_take_hdl(NCS_SERVICE_ID_AVA, hdl)) ) {
 rc = SA_AIS_ERR_BAD_HANDLE;

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
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 amfa: return SA_AIS_ERR_VERSION from saAmfComponentUnregister [#171]

2016-11-07 Thread nagendra . k
Summary: amfa: return SA_AIS_ERR_VERSION from saAmfComponentUnregister [#171]
Review request for Trac Ticket(s): #171
Peer Reviewer(s): Amf Dev 
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 fbdd799bc4874175c650154b531a29053f488e50
Author: Nagendra Kumar
Date:   Tue, 08 Nov 2016 10:20:34 +0530

amfa: return SA_AIS_ERR_VERSION from saAmfComponentUnregister [#171]


Complete diffstat:
--
 osaf/libs/agents/saf/amfa/amf_agent.cc |  8 
 1 files changed, 8 insertions(+), 0 deletions(-)


Testing Commands:
-
Call saAmfComponentUnregister with AMf B4.1 version initialized handle.

Testing, Expected Results:
--
Amfa trace :
Invalid AMF version, B 4.1

Conditions of Submission:
-
Ack from Amf 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.


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
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: return SA_AIS_ERR_NO_OP for error clear api [#245]

2016-11-06 Thread nagendra . k
Summary: amfnd: return SA_AIS_ERR_NO_OP for error clear api  [#245]
Review request for Trac Ticket(s): #245
Peer Reviewer(s): Amf Dev
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 19eee7af0a59a57de457d0425108bfe0521784ff
Author: Nagendra Kumar
Date:   Mon, 07 Nov 2016 10:51:59 +0530

amfnd: return SA_AIS_ERR_NO_OP for error clear api [#245]


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


Testing Commands:
-
syslog(LOG_ERR, "= Calling Err Clear ");
SaNtfCorrelationIdsT *corr_ids=malloc(sizeof(SaNtfCorrelationIdsT));
corr_ids->rootCorrelationId = SA_NTF_IDENTIFIER_UNUSED;
corr_ids->parentCorrelationId = SA_NTF_IDENTIFIER_UNUSED;
rc = saAmfComponentErrorClear_4(my_amf_hdl, _comp_name, corr_ids);
if (rc != SA_AIS_OK) {
syslog(LOG_ERR, "1.saAmfComponentErrorReport FAILED - %u", rc);
} else
syslog(LOG_ERR, "1. saAmfComponentErrorReport Success - %u", 
rc);


Testing, Expected Results:
--
Nov  7 11:31:37 PM_SC-1 amf_demo[9640]: = Calling Err Clear
Nov  7 11:31:37 PM_SC-1 amf_demo[9640]: 1.saAmfComponentErrorReport FAILED - 28


Conditions of Submission:
-
Ack from Amf Dev

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.


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net

[devel] [PATCH 1 of 1] amfnd: return SA_AIS_ERR_NO_OP for error clear api [#245]

2016-11-06 Thread nagendra . k
 osaf/services/saf/amf/amfnd/err.cc |  3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)


diff --git a/osaf/services/saf/amf/amfnd/err.cc 
b/osaf/services/saf/amf/amfnd/err.cc
--- a/osaf/services/saf/amf/amfnd/err.cc
+++ b/osaf/services/saf/amf/amfnd/err.cc
@@ -270,6 +270,9 @@ uint32_t avnd_evt_ava_err_clear_evh(AVND
(!m_AVND_COMP_TYPE_IS_PREINSTANTIABLE(comp) && 
!m_AVND_COMP_TYPE_IS_PROXIED(comp)))
amf_rc = SA_AIS_ERR_BAD_OPERATION;
 
+   if (m_AVND_COMP_OPER_STATE_IS_ENABLED(comp))
+   amf_rc = SA_AIS_ERR_NO_OP;
+
/* send the response back to AvA */
rc = avnd_amf_resp_send(cb, AVSV_AMF_ERR_CLEAR, amf_rc, 0,
_info->dest, >mds_ctxt, comp, 
msg_from_avnd);

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
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 amfa: add SA_AIS_ERR_NOT_EXIST as return error code [#251]

2016-11-04 Thread nagendra . k
Summary: amfa: add SA_AIS_ERR_NOT_EXIST as return error code [#251]
Review request for Trac Ticket(s): #251
Peer Reviewer(s): Amf Dev
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 c7bb477ea206af2d25420587d855c961772598c2
Author: Nagendra Kumar
Date:   Fri, 04 Nov 2016 16:41:35 +0530

amfa: add SA_AIS_ERR_NOT_EXIST as return error code [#251]


Complete diffstat:
--
 osaf/libs/agents/saf/amfa/amf_agent.cc |  9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)


Testing Commands:
-
1. Tested with saAmfResponse_4 by passing invalid handle.
2. Tested with saAmfResponse by passing invalid handle.

Testing, Expected Results:
--
1. Got SA_AIS_ERR_NOT_EXIST as return code.
2. Got SA_AIS_ERR_INVALID_PARAM as return code.

Conditions of Submission:
-
Ack from Amf Dev

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.


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfa: add SA_AIS_ERR_NOT_EXIST as return error code [#251]

2016-11-04 Thread nagendra . k
 osaf/libs/agents/saf/amfa/amf_agent.cc |  9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)


diff --git a/osaf/libs/agents/saf/amfa/amf_agent.cc 
b/osaf/libs/agents/saf/amfa/amf_agent.cc
--- a/osaf/libs/agents/saf/amfa/amf_agent.cc
+++ b/osaf/libs/agents/saf/amfa/amf_agent.cc
@@ -2014,9 +2014,12 @@ SaAisErrorT AmfAgent::Response(SaAmfHand
   /* get the pending response rec from list */
   m_AVA_HDL_PEND_RESP_GET(list_resp, rec, inv);
   if (!rec) {
-TRACE_2("No pending response records found for this handle");
-rc = SA_AIS_ERR_INVALID_PARAM;
-goto done;
+ TRACE_2("No pending response records found for this handle");
+ if(ava_B4_ver_used(cb))
+ rc = SA_AIS_ERR_NOT_EXIST;
+ else
+ rc = SA_AIS_ERR_INVALID_PARAM;
+ goto done;
   }
 
   /* populate & send the 'AMF response' message */

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
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: add logs for HC start failures [#340]

2016-11-04 Thread nagendra . k
Summary: amfnd: add logs for HC start failures [#340]
Review request for Trac Ticket(s): #340
Peer Reviewer(s): Amf Dev
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 3c9be33fa39c29690c77be6b94bb91dec8190422
Author: Nagendra Kumar
Date:   Fri, 04 Nov 2016 14:00:18 +0530

amfnd: add logs for HC start failures [#340]


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


Testing Commands:
-
Compiled

Testing, Expected Results:
--


Conditions of Submission:
-
Ack from Amf Dev

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.


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfnd: add logs for HC start failures [#340]

2016-11-04 Thread nagendra . k
 osaf/services/saf/amf/amfnd/chc.cc |  7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)


diff --git a/osaf/services/saf/amf/amfnd/chc.cc 
b/osaf/services/saf/amf/amfnd/chc.cc
--- a/osaf/services/saf/amf/amfnd/chc.cc
+++ b/osaf/services/saf/amf/amfnd/chc.cc
@@ -315,6 +315,7 @@ void avnd_comp_hc_param_val(AVND_CB *cb,
 
/* get the comp */
if ((*o_comp = avnd_compdb_rec_get(cb->compdb, 
Amf::to_string(_start->comp_name))) == nullptr) {
+   LOG_ER("Component '%s' doesn't exist in DB", 
osaf_extended_name_borrow(_start->comp_name));
*o_amf_rc = SA_AIS_ERR_NOT_EXIST;
return;
}
@@ -324,6 +325,8 @@ void avnd_comp_hc_param_val(AVND_CB *cb,

m_AVND_COMP_PRES_STATE_IS_INSTANTIATIONFAILED(*o_comp) ||
m_AVND_COMP_PRES_STATE_IS_TERMINATING(*o_comp) ||

m_AVND_COMP_PRES_STATE_IS_TERMINATIONFAILED(*o_comp)) {
+   LOG_ER("Component '%s' is not healthy (pres 
state '%u')", osaf_extended_name_borrow(_start->comp_name),
+   (*o_comp)->pres);
*o_amf_rc = SA_AIS_ERR_TRY_AGAIN;
return;
}
@@ -347,6 +350,8 @@ void avnd_comp_hc_param_val(AVND_CB *cb,
if (0 == avnd_hcdb_rec_get(cb, _chk)) {
/* HC instance did not exist, look for HC type 
*/
if (nullptr == avnd_hctypedb_rec_get(cb, 
(*o_comp)->saAmfCompType, _start->hc_key)) {
+   LOG_ER("Health check is not configured 
for component '%s'",
+   
osaf_extended_name_borrow(_start->comp_name));
*o_amf_rc = SA_AIS_ERR_NOT_EXIST;
return;
}
@@ -356,6 +361,8 @@ void avnd_comp_hc_param_val(AVND_CB *cb,
tmp_hc_rec.req_hdl = hc_start->hdl;
/* determine if this healthcheck is already active */
if (0 != m_AVND_COMPDB_REC_HC_GET(**o_comp, 
tmp_hc_rec)) {
+   LOG_ER("Health check is already active for 
component '%s'",
+   
osaf_extended_name_borrow(_start->comp_name));
*o_amf_rc = SA_AIS_ERR_EXIST;
return;
}

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: add support of saAmfSUAssignedSIs [#905]

2016-11-03 Thread nagendra . k
 osaf/services/saf/amf/amfd/imm.cc|  63 
 osaf/services/saf/amf/amfd/include/imm.h |   7 +++
 osaf/services/saf/amf/amfd/su.cc |  31 ---
 3 files changed, 95 insertions(+), 6 deletions(-)


diff --git a/osaf/services/saf/amf/amfd/imm.cc 
b/osaf/services/saf/amf/amfd/imm.cc
--- a/osaf/services/saf/amf/amfd/imm.cc
+++ b/osaf/services/saf/amf/amfd/imm.cc
@@ -1635,6 +1635,69 @@ SaAisErrorT avd_saImmOiRtObjectUpdate_sy
 }
 
 /**
+ * IM object update, BLOCKING. It updates multivalue attributes.
+ * @param dn
+ * @param attributeName
+ * @param attrValueType
+ * @param attrValues
+ * @param assigned_si
+ */
+SaAisErrorT avd_saImmOiRtObjectUpdate_multival_sync(const std::string& dn, 
SaImmAttrNameT attributeName,
+   SaImmValueTypeT attrValueType, SaImmAttrValueT *attrValues, 
uint32_t assigned_si,
+   SaImmAttrModificationTypeT modifyType)
+{
+   SaAisErrorT rc;
+   SaImmAttrModificationT_2 attrMod;
+   const SaImmAttrModificationT_2 *attrMods[] = {, nullptr};
+
+   TRACE_ENTER2("'%s' %s", dn.c_str(), attributeName);
+
+   attrMod.modType = modifyType;
+   attrMod.modAttr.attrName = attributeName;
+   attrMod.modAttr.attrValuesNumber = assigned_si;
+   attrMod.modAttr.attrValueType = attrValueType;
+   attrMod.modAttr.attrValues = attrValues;
+
+   rc = saImmOiRtObjectUpdate_o3(avd_cb->immOiHandle, dn.c_str(), 
attrMods);
+   if (rc != SA_AIS_OK) {
+   LOG_WA("saImmOiRtObjectUpdate of '%s' %s failed with %u",
+   dn.c_str(), attributeName, rc);
+   }
+   return rc;
+}
+
+
+/**
+ * IM object update, BLOCKING. It replaces the attr values to null.
+ * @param dn
+ * @param attributeName
+ * @param attrValueType
+ * @param value
+ */
+SaAisErrorT avd_saImmOiRtObjectUpdate_replace_sync(const std::string& dn, 
SaImmAttrNameT attributeName,
+   SaImmValueTypeT attrValueType, void *value,
+   SaImmAttrModificationTypeT modifyType)
+{
+   SaAisErrorT rc;
+   SaImmAttrModificationT_2 attrMod;
+   const SaImmAttrModificationT_2 *attrMods[] = {, nullptr};
+
+   TRACE_ENTER2("'%s' %s", dn.c_str(), attributeName);
+
+   attrMod.modType = SA_IMM_ATTR_VALUES_REPLACE;
+   attrMod.modAttr.attrName = attributeName;
+   attrMod.modAttr.attrValuesNumber = 0;
+   attrMod.modAttr.attrValueType = attrValueType;
+
+   rc = saImmOiRtObjectUpdate_o3(avd_cb->immOiHandle, dn.c_str(), 
attrMods);
+   if (rc != SA_AIS_OK) {
+   LOG_WA("saImmOiRtObjectUpdate of '%s' %s failed with %u",
+   dn.c_str(), attributeName, rc);
+   }
+   return rc;
+}
+
+/**
  * @brief   As of now standby AMFD will maintain immjobs for object of few 
classes.
  *  This function checks if immjobs for this object can be maintained 
at standby. 
  *
diff --git a/osaf/services/saf/amf/amfd/include/imm.h 
b/osaf/services/saf/amf/amfd/include/imm.h
--- a/osaf/services/saf/amf/amfd/include/imm.h
+++ b/osaf/services/saf/amf/amfd/include/imm.h
@@ -153,6 +153,13 @@ extern unsigned int avd_imm_config_get(v
 extern SaAisErrorT avd_saImmOiRtObjectUpdate_sync(const std::string& dn,
SaImmAttrNameT attributeName, SaImmValueTypeT attrValueType, 
void *value,
SaImmAttrModificationTypeT modifyType = 
SA_IMM_ATTR_VALUES_REPLACE);
+extern SaAisErrorT avd_saImmOiRtObjectUpdate_multival_sync(const std::string& 
dn,
+   SaImmAttrNameT attributeName, SaImmValueTypeT attrValueType, 
SaImmAttrValueT *value,
+   uint32_t assigned_si,
+   SaImmAttrModificationTypeT modifyType = 
SA_IMM_ATTR_VALUES_REPLACE);
+extern SaAisErrorT avd_saImmOiRtObjectUpdate_replace_sync(const std::string& 
dn,
+   SaImmAttrNameT attributeName, SaImmValueTypeT attrValueType, 
void *value,
+   SaImmAttrModificationTypeT modifyType = 
SA_IMM_ATTR_VALUES_REPLACE);
 extern void avd_saImmOiRtObjectUpdate(const std::string& dn, const 
std::string& attributeName,
  SaImmValueTypeT attrValueType, void* value);
 extern void avd_saImmOiRtObjectCreate(const std::string& lassName,
diff --git a/osaf/services/saf/amf/amfd/su.cc b/osaf/services/saf/amf/amfd/su.cc
--- a/osaf/services/saf/amf/amfd/su.cc
+++ b/osaf/services/saf/amf/amfd/su.cc
@@ -1390,12 +1390,31 @@ static SaAisErrorT su_rt_attr_cb(SaImmOi
 
while ((attributeName = attributeNames[i++]) != nullptr) {
if (!strcmp("saAmfSUAssignedSIs", attributeName)) {
-#if 0
-   /*  TODO */
-   SaUint32T saAmfSUAssignedSIs = 
su->saAmfSUNumCurrActiveSIs + su->saAmfSUNumCurrStandbySIs;
-   avd_saImmOiRtObjectUpdate_sync(immOiHandle, objectName,
-   attributeName, SA_IMM_ATTR_SAUINT32T, 
);
-#endif
+   if (su->list_of_susi != nullptr) {
+   

[devel] [PATCH 0 of 1] Review Request for amfd: add support of saAmfSUAssignedSIs [#905]

2016-11-03 Thread nagendra . k
Summary: amfd: add support of saAmfSUAssignedSIs [#905]
Review request for Trac Ticket(s): #905
Peer Reviewer(s): Amf Dev
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 3bcdf574f912fc71c6f6f27c4e3ee3bccd80af80
Author: Nagendra Kumar
Date:   Thu, 03 Nov 2016 14:57:52 +0530

amfd: add support of saAmfSUAssignedSIs [#905]


Complete diffstat:
--
 osaf/services/saf/amf/amfd/imm.cc|  63 
+++
 osaf/services/saf/amf/amfd/include/imm.h |   7 +++
 osaf/services/saf/amf/amfd/su.cc |  31 +--
 3 files changed, 95 insertions(+), 6 deletions(-)


Testing Commands:
-
1. SU1 is Act and SU2 is Standby having 4 SIs each.

immlist safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 -a saAmfSUAssignedSIs
saAmfSUAssignedSIs=safSi=AmfDemo1,safApp=AmfDemo1:safSi=AmfDemo2,safApp=AmfDemo1:safSi=AmfDemo3,safApp=AmfDemo1:safSi=AmfDemo4,safApp=AmfDemo1
immlist safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 -a saAmfSUAssignedSIs
saAmfSUAssignedSIs=safSi=AmfDemo1,safApp=AmfDemo1:safSi=AmfDemo2,safApp=AmfDemo1:safSi=AmfDemo3,safApp=AmfDemo1:safSi=AmfDemo4,safApp=AmfDemo1

2. Lock SU1. There is no susi on SU1.
immlist safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 -a saAmfSUAssignedSIs
saAmfSUAssignedSIs=
immlist safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 -a saAmfSUAssignedSIs
saAmfSUAssignedSIs=safSi=AmfDemo1,safApp=AmfDemo1:safSi=AmfDemo2,safApp=AmfDemo1:safSi=AmfDemo3,safApp=AmfDemo1:safSi=AmfDemo4,safApp=AmfDemo1

3. Unlock SU1 and lock SI2. There is no SI2 assignments below.
immlist safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 -a saAmfSUAssignedSIs
saAmfSUAssignedSIs=safSi=AmfDemo1,safApp=AmfDemo1:safSi=AmfDemo3,safApp=AmfDemo1:safSi=AmfDemo4,safApp=AmfDemo1
immlist safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 -a saAmfSUAssignedSIs
saAmfSUAssignedSIs=safSi=AmfDemo1,safApp=AmfDemo1:safSi=AmfDemo3,safApp=AmfDemo1:safSi=AmfDemo4,safApp=AmfDemo1


Testing, Expected Results:
--
As shown above.

Conditions of Submission:
-
Ack from Amf Dev

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 0 of 1] Review Request for amf: add more information in logging [#1918]

2016-11-01 Thread nagendra . k
Summary: amf: add more information in logging [#1918]
Review request for Trac Ticket(s): #1918
Peer Reviewer(s): Amf Dev 
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 625a943dca8981d9ac54db536b73a9f1d2dea69f
Author: Nagendra Kumar
Date:   Tue, 01 Nov 2016 16:24:39 +0530

amf: add more information in logging [#1918]


Complete diffstat:
--
 osaf/services/saf/amf/amfd/clm.cc   |  3 ++-
 osaf/services/saf/amf/amfd/ndfsm.cc |  4 +++-
 osaf/services/saf/amf/amfd/ndproc.cc|  6 +++---
 osaf/services/saf/amf/amfd/pg.cc|  2 +-
 osaf/services/saf/amf/amfd/sg_2n_fsm.cc |  2 +-
 osaf/services/saf/amf/amfd/sgproc.cc|  7 ---
 osaf/services/saf/amf/amfd/su.cc|  6 --
 osaf/services/saf/amf/amfnd/di.cc   |  2 +-
 8 files changed, 19 insertions(+), 13 deletions(-)


Testing Commands:
-
Compiled

Testing, Expected Results:
--
No error.

Conditions of Submission:
-
Ack from Amf Dev

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.


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amf: add more information in logging [#1918]

2016-11-01 Thread nagendra . k
 osaf/services/saf/amf/amfd/clm.cc   |  3 ++-
 osaf/services/saf/amf/amfd/ndfsm.cc |  4 +++-
 osaf/services/saf/amf/amfd/ndproc.cc|  6 +++---
 osaf/services/saf/amf/amfd/pg.cc|  2 +-
 osaf/services/saf/amf/amfd/sg_2n_fsm.cc |  2 +-
 osaf/services/saf/amf/amfd/sgproc.cc|  7 ---
 osaf/services/saf/amf/amfd/su.cc|  6 --
 osaf/services/saf/amf/amfnd/di.cc   |  2 +-
 8 files changed, 19 insertions(+), 13 deletions(-)


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
@@ -60,7 +60,8 @@ static void clm_node_join_complete(AVD_A

su->set_term_state(false);

su->sg_of_su->try_inst_counter++;
} else {
-   LOG_ER("Internal error, 
could not send message to avnd");
+   LOG_ER("Internal error, 
could not send SU'%s' pres message to avnd '%x'",
+   
su->name.c_str(), su->su_on_node->node_info.nodeId);
}
}
}
diff --git a/osaf/services/saf/amf/amfd/ndfsm.cc 
b/osaf/services/saf/amf/amfd/ndfsm.cc
--- a/osaf/services/saf/amf/amfd/ndfsm.cc
+++ b/osaf/services/saf/amf/amfd/ndfsm.cc
@@ -306,7 +306,9 @@ void avd_node_up_evh(AVD_CL_CB *cb, AVD_
cb->node_sync_window_closed == false) {
avnd = 
avd_node_get(Amf::to_string(_msg->msg_info.n2d_node_up.node_name));
if (avnd == nullptr) {
-   LOG_ER("Invalid node_name. Check node_id");
+   LOG_ER("Invalid node_name '%s'. Check node_id '%x'",
+   
osaf_extended_name_borrow(_msg->msg_info.n2d_node_up.node_name),
+   n2d_msg->msg_info.n2d_node_up.node_id);
 
// perhaps this is a node_up from an old version of 
amfnd without headless support
// let's check if the node_id is valid
diff --git a/osaf/services/saf/amf/amfd/ndproc.cc 
b/osaf/services/saf/amf/amfd/ndproc.cc
--- a/osaf/services/saf/amf/amfd/ndproc.cc
+++ b/osaf/services/saf/amf/amfd/ndproc.cc
@@ -111,7 +111,7 @@ void avd_reg_su_evh(AVD_CL_CB *cb, AVD_E
}
 
if ((node->node_state == AVD_AVND_STATE_ABSENT) || (node->node_state == 
AVD_AVND_STATE_GO_DOWN)) {
-   LOG_ER("%s: invalid node state %u", __FUNCTION__, 
node->node_state);
+   LOG_ER("%s: invalid node state %u for node id '%u'", 
__FUNCTION__, node->node_state, n2d_msg->msg_info.n2d_reg_su.node_id);
avsv_dnd_msg_free(n2d_msg);
evt->info.avnd_msg = nullptr;
goto done;
@@ -244,7 +244,7 @@ void avd_oper_req_evh(AVD_CL_CB *cb, AVD
}
 
if ((node->node_state == AVD_AVND_STATE_ABSENT) || (node->node_state == 
AVD_AVND_STATE_GO_DOWN)) {
-   LOG_ER("%s: invalid node state %u", __FUNCTION__, 
node->node_state);
+   LOG_ER("%s: invalid node state %u for node id '%u'", 
__FUNCTION__, node->node_state, n2d_msg->msg_info.n2d_op_req.node_id);
goto done;
}
 
@@ -1098,7 +1098,7 @@ void avd_comp_validation_evh(AVD_CL_CB *
}
 
if ((node->node_state == AVD_AVND_STATE_ABSENT) || (node->node_state == 
AVD_AVND_STATE_GO_DOWN)) {
-   LOG_ER("%s: invalid node state %u", __FUNCTION__, 
node->node_state);
+   LOG_ER("%s: invalid node state %u for node id '%u'", 
__FUNCTION__, node->node_state, valid_info->node_id);
avsv_dnd_msg_free(n2d_msg);
evt->info.avnd_msg = nullptr;
goto done;
diff --git a/osaf/services/saf/amf/amfd/pg.cc b/osaf/services/saf/amf/amfd/pg.cc
--- a/osaf/services/saf/amf/amfd/pg.cc
+++ b/osaf/services/saf/amf/amfd/pg.cc
@@ -77,7 +77,7 @@ void avd_pg_trk_act_evh(AVD_CL_CB *cb, A
m_AVD_SET_AVND_RCV_ID(cb, node, (n2d_msg->msg_info.n2d_reg_su.msg_id));
 
if ((node->node_state == AVD_AVND_STATE_ABSENT) || (node->node_state == 
AVD_AVND_STATE_GO_DOWN)) {
-   LOG_ER("%s: invalid node state %u", __FUNCTION__, 
node->node_state);
+   LOG_ER("%s: invalid node state %u for node id '%u'", 
__FUNCTION__, node->node_state, info->node_id);
goto done;
}
 
diff --git a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc 
b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
--- a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
+++ b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
@@ -1398,7 +1398,7 @@ uint32_t SG_2N::su_insvc(AVD_CL_CB *cb, 
/* An SU will not become in service when the SG is being locked or 
shutdown.
 */
  

[devel] [PATCH 1 of 1] amfd: remove db_template.h file [#2078]

2016-11-01 Thread nagendra . k
 osaf/services/saf/amf/amfd/include/db_template.h |  93 
 1 files changed, 0 insertions(+), 93 deletions(-)


diff --git a/osaf/services/saf/amf/amfd/include/db_template.h 
b/osaf/services/saf/amf/amfd/include/db_template.h
deleted file mode 100644
--- a/osaf/services/saf/amf/amfd/include/db_template.h
+++ /dev/null
@@ -1,93 +0,0 @@
-/*  -*- OpenSAF  -*-
- *
- * (C) Copyright 2014 The OpenSAF Foundation
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
- * or FITNESS FOR A PARTICULAR PURPOSE. This file and program are licensed
- * under the GNU Lesser General Public License Version 2.1, February 1999.
- * The complete license can be accessed from the following location:
- * http://opensource.org/licenses/lgpl-license.php
- * See the Copying file included with the OpenSAF distribution for full
- * licensing terms.
- *
- * Author(s): Ericsson AB
- *
- */
-#ifndef DB_TEMPLATE_H
-#defineDB_TEMPLATE_H
-
-#include 
-#include 
-#include "saAis.h"
-#include "ncsgl_defs.h"
-
-//
-class Amf {
-public:
-  static std::string to_string(const SaNameT *name) {
- return std::string((char*)name->value, name->length);
-  }
-};
-
-//
-template 
-class AmfDb {
-  public:
-   unsigned int insert(const Key , T *obj);
-   void erase(const Key );
-   T *find(const Key );
-   
-   typedef std::map AmfDbMap;
-   typedef typename AmfDbMap::const_iterator const_iterator;
-   typedef typename AmfDbMap::iterator iterator;
-   typedef typename AmfDbMap::const_reverse_iterator const_reverse_iterator;
-
-   const_iterator begin() const {return db.begin();}
-   const_iterator end() const {return db.end();}
-   typename AmfDbMap::size_type size() const {return db.size();}
-   const_reverse_iterator rbegin() const {return db.rbegin();}
-   const_reverse_iterator rend() const {return db.rend();}
-
-   iterator erase(const iterator ) {return db.erase(it);}
-
-   iterator begin() {return db.begin();}
-   iterator end() {return db.end();}
-
-   const_iterator cbegin() const {return db.cbegin();}
-   const_iterator cend() const {return db.cend();}
-
-  private:
-   AmfDbMap db;
-};
-
-//
-template 
-unsigned int AmfDb::insert(const Key , T *obj) {
-  osafassert(obj);
-  
-  if (db.insert(std::make_pair(key, obj)).second) {
-return 1; // NCSCC_RC_SUCCESS
-  }
-   else {
-  return 2; // Duplicate (NCSCC_RC_FAILURE)
-}
- }
-
-//
-template 
-void AmfDb::erase(const Key ) {
-  db.erase(key);
-}
-
-//
-template 
-T *AmfDb::find(const Key ) {
-  typename AmfDbMap::iterator it = db.find(key);
-  if (it == db.end())
-return 0;
-  else
-return it->second;
-}
-
-#endif /* DB_TEMPLATE_H */

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
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 db_template.h file [#2078]

2016-11-01 Thread nagendra . k
Summary: amfd: remove db_template.h file [#2078]
Review request for Trac Ticket(s): #2078
Peer Reviewer(s): Amf Dev
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 47fcedc517317ebc31d62c1260c85d744e4a7e8f
Author: Nagendra Kumar
Date:   Tue, 01 Nov 2016 14:19:19 +0530

amfd: remove db_template.h file [#2078]


Removed Files:
--
 osaf/services/saf/amf/amfd/include/db_template.h


Complete diffstat:
--
 osaf/services/saf/amf/amfd/include/db_template.h |  93 
-
 1 files changed, 0 insertions(+), 93 deletions(-)


Testing Commands:
-
Compiled.

Testing, Expected Results:
--
Compiled successfully.

Conditions of Submission:
-
Ack from Amf Dev

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.


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfnd: avoid sending SUSI resp during recovery [#1931]

2016-08-03 Thread nagendra . k
 osaf/services/saf/amf/amfnd/susm.cc |  4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)


During component failover recovery (NPI SU), Amfnd
attempt to send SUSI resp to Amfd though there is
no SUSI assignment is undergoing.
NPI SU terminating state is not a reflective of
SUSI assignment rather it can be during recovery
phases also.

diff --git a/osaf/services/saf/amf/amfnd/susm.cc 
b/osaf/services/saf/amf/amfnd/susm.cc
--- a/osaf/services/saf/amf/amfnd/susm.cc
+++ b/osaf/services/saf/amf/amfnd/susm.cc
@@ -1832,7 +1832,9 @@ uint32_t avnd_su_pres_st_chng_prc(AVND_C
rc = avnd_di_oper_send(cb, su, 
SA_AMF_COMPONENT_FAILOVER);
 
/* si assignment/removal failed.. inform AvD */
-   rc = avnd_di_susi_resp_send(cb, su, 
m_AVND_SU_IS_ALL_SI(su) ? 0 : si);
+   /* Send response to Amfd only when there is a pending 
assignment. */
+   if (m_AVND_SU_IS_ASSIGN_PEND(su))
+   rc = avnd_di_susi_resp_send(cb, su, 
m_AVND_SU_IS_ALL_SI(su) ? 0 : si);
}
 
/* instantiating -> term-failed */

--
___
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: avoid sending SUSI resp during recovery [#1931]

2016-08-03 Thread nagendra . k
Summary: amfnd: avoid sending SUSI resp during recovery [#1931]
Review request for Trac Ticket(s): #1931
Peer Reviewer(s): Amf Dev
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 5a658efc90c6367c4a37bfb3f9bd6db5d83f5321
Author: Nagendra Kumar
Date:   Thu, 04 Aug 2016 10:39:02 +0530

amfnd: avoid sending SUSI resp during recovery [#1931] During component
failover recovery (NPI SU), Amfnd attempt to send SUSI resp to Amfd 
though
there is no SUSI assignment is undergoing. NPI SU terminating state is 
not a
reflective of SUSI assignment rather it can be during recovery phases 
also.

P.S. : Please note that SU repair after component failover is failing for
non-headless case, but works fine for headless case.



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


Testing Commands:
-
As per ticket.

Testing, Expected Results:
--
Amfnd doesn't crash.

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.


--
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: mark stby_sync_state out of sync if peer amfd is absent [#1850]

2016-08-02 Thread nagendra . k
 osaf/services/saf/amf/amfd/main.cc  |  2 +-
 osaf/services/saf/amf/amfd/sg_2n_fsm.cc |  3 ++-
 osaf/services/saf/amf/amfd/sgproc.cc|  8 +---
 3 files changed, 4 insertions(+), 9 deletions(-)


If standby amfd is not available then stby_sync_state
should be in out of sync state.
Else, Amfd should be in out of sync state.
This is to avoid issues like 1841

diff --git a/osaf/services/saf/amf/amfd/main.cc 
b/osaf/services/saf/amf/amfd/main.cc
--- a/osaf/services/saf/amf/amfd/main.cc
+++ b/osaf/services/saf/amf/amfd/main.cc
@@ -542,7 +542,7 @@ static uint32_t initialize(void)
cb->fully_initialized = false;
cb->swap_switch = false;
cb->active_services_exist = true;
-   cb->stby_sync_state = AVD_STBY_IN_SYNC;
+   cb->stby_sync_state = AVD_STBY_OUT_OF_SYNC;
cb->sync_required = true;

cb->heartbeat_tmr.is_active = false;
diff --git a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc 
b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
--- a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
+++ b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
@@ -771,7 +771,8 @@ SaAisErrorT SG_2N::si_swap(AVD_SI *si, S
goto done;
}
 
-   if (si->sg_of_si->sg_ncs_spec) {
+   if ((si->sg_of_si->sg_ncs_spec) && 
+   ((cb->node_id_avd_other != 0) && (cb->other_avd_adest 
!= 0))) {
if (avd_cb->stby_sync_state == AVD_STBY_OUT_OF_SYNC) {
LOG_ER("%s SWAP failed - Cold sync in progress", 
si->name.value);
rc = SA_AIS_ERR_TRY_AGAIN;
diff --git a/osaf/services/saf/amf/amfd/sgproc.cc 
b/osaf/services/saf/amf/amfd/sgproc.cc
--- a/osaf/services/saf/amf/amfd/sgproc.cc
+++ b/osaf/services/saf/amf/amfd/sgproc.cc
@@ -1997,14 +1997,8 @@ void avd_node_down_mw_susi_failover(AVD_
if ((i_su->sg_of_su->sg_redundancy_model == 
SA_AMF_2N_REDUNDANCY_MODEL) &&
(i_su->sg_of_su->sg_fsm_state == 
AVD_SG_FSM_STABLE))
(void) avd_clm_track_start();
-   /* If Std ctlr went down in middle of Cold sync, then we need
-  to reset the sync state to IN_SYNC. */
-   if ((i_su->sg_of_su->sg_redundancy_model == 
SA_AMF_2N_REDUNDANCY_MODEL) &&
-   (cb->stby_sync_state == AVD_STBY_OUT_OF_SYNC)) {
-   TRACE("Marking sync_state as in_sync");
-   cb->stby_sync_state = AVD_STBY_IN_SYNC;
-   }
/* Free all the SU SI assignments*/ 
+
i_su->delete_all_susis();
 
}   /* for (const auto& i_su : avnd->list_of_su) */

--
___
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: mark stby_sync_state out of sync if peer amfd is absent [#1850]

2016-08-02 Thread nagendra . k
Summary: amfd: mark stby_sync_state out of sync if peer amfd is absent [#1850]
Review request for Trac Ticket(s): #1850
Peer Reviewer(s): Amf Developers
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 b2c7e396ef3f39eab2176cd69371259582633593
Author: Nagendra Kumar
Date:   Tue, 02 Aug 2016 17:26:14 +0530

amfd: mark stby_sync_state out of sync if peer amfd is absent [#1850] If
standby amfd is not available then stby_sync_state should be in out of 
sync
state. Else, Amfd should be in out of sync state. This is to avoid 
issues
like 1841


Complete diffstat:
--
 osaf/services/saf/amf/amfd/main.cc  |  2 +-
 osaf/services/saf/amf/amfd/sg_2n_fsm.cc |  3 ++-
 osaf/services/saf/amf/amfd/sgproc.cc|  8 +---
 3 files changed, 4 insertions(+), 9 deletions(-)


Testing Commands:
-
1. Perform some switchover and failovers.
2. Keep delay in cold sync on stdby amfd and while cold sync is
   undergoing , perform si swap.

Testing, Expected Results:
--
1. All should pass.
2. Should get the following error for some time, before si swap suceeds:
"SWAP failed - Cold sync in progress"

Conditions of Submission:
-
Ack

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.


--
___
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: during headless donot read config from imm [#1916]

2016-07-18 Thread nagendra . k
Summary: amfnd: during headless donot read config from imm [#1916]
Review request for Trac Ticket(s): #1916
Peer Reviewer(s): Amf Dev
Pull request to: <>
Affected branch(es): 5.0.x
Development branch: 5.0.x


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 163876cb89a860df56381ea2afb1c0ef7456f580
Author: Nagendra Kumar
Date:   Mon, 18 Jul 2016 18:04:11 +0530

amfnd: during headless donot read config from imm [#1916] During 
headless,
IMM returns TRY_AGAIN. Also, if Imm is restarted during headless state, 
Imm
returns TRY_AGAIN. If Amfnd waits for TRY_AGAIN, then Amf Watchdog will 
kill
it. So, Amfnd should not read imm config and reuse the old config for
instantiating a component.


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


Testing Commands:
-
Please check the ticket.

Testing, Expected Results:
--
Component should be restarted successfully.

Conditions of Submission:
-
Ack from Amf Dev

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.


--
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 amfnd: ignore cleanup succ event during shutdown [#1915]

2016-07-15 Thread nagendra . k
Summary: amfnd: ignore cleanup succ event during shutdown [#1915]
Review request for Trac Ticket(s): #1915
Peer Reviewer(s): Amf Dev
Pull request to: <>
Affected branch(es): All
Development branch: 5.0.x 


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 9a9c032a153338f159389b57e120b2ae8e06e75a
Author: Nagendra Kumar
Date:   Fri, 15 Jul 2016 11:31:18 +0530

amfnd: ignore cleanup succ event during shutdown [#1915] When opensafd 
is
shutting down, the cleanup succ event of component should be ignored
because, there is no further event need to occur for another comp ot su.


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


Testing Commands:
-
Please check the ticket.

Testing, Expected Results:
--
Amfnd shouldn't generate core dump.

Conditions of Submission:
-
Ack

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.


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


[devel] [PATCH 1 of 1] amfnd: ignore cleanup succ event during shutdown [#1915]

2016-07-15 Thread nagendra . k
 osaf/services/saf/amf/amfnd/clc.cc |  22 ++
 1 files changed, 22 insertions(+), 0 deletions(-)


When opensafd is shutting down, the cleanup succ event
of component should be ignored because, there is no
further event need to occur for another comp ot su.

diff --git a/osaf/services/saf/amf/amfnd/clc.cc 
b/osaf/services/saf/amf/amfnd/clc.cc
--- a/osaf/services/saf/amf/amfnd/clc.cc
+++ b/osaf/services/saf/amf/amfnd/clc.cc
@@ -809,6 +809,28 @@ uint32_t avnd_comp_clc_fsm_run(AVND_CB *
}
}
 
+   if ((cb->term_state == AVND_TERM_STATE_OPENSAF_SHUTDOWN_STARTED) &&
+   m_AVND_SU_IS_PREINSTANTIABLE(comp->su) &&
+   (!m_AVND_COMP_TYPE_IS_PREINSTANTIABLE(comp)) &&
+   (comp->pres == SA_AMF_PRESENCE_TERMINATING)) {
+   TRACE("Term state is SHUTDOWN STARTED, event '%s'", 
pres_state_evt[ev]);
+   switch (ev) {
+   case AVND_COMP_CLC_PRES_FSM_EV_CLEANUP_SUCC:
+   avnd_comp_pres_state_set(cb, comp, 
SA_AMF_PRESENCE_UNINSTANTIATED);
+   if (all_comps_terminated()) {
+   LOG_NO("Terminated all AMF components");
+   LOG_NO("Shutdown completed, exiting");
+   exit(0);
+   } else {
+   TRACE("Do nothing");
+   goto done;
+   }
+   default:
+   LOG_ER("Ignoring event '%s' for '%s' during 
node shutdown",
+   pres_state_evt[ev], 
comp->name.value);
+   goto done;
+   }
+   }
/* get the prv presence state */
prv_st = comp->pres;
 

--
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 amfnd: donot read configuration for mw comp [#369]

2016-07-12 Thread nagendra . k
Summary: amfnd: donot read configuration for mw comp [#369]
Review request for Trac Ticket(s): #369
Peer Reviewer(s): Amf Develoers
Pull request to: <>
Affected branch(es): 5.0.x and default
Development branch: 5.0.x


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 cf1258feadc23ebad2087cf22fc117a12d441956
Author: Nagendra Kumar
Date:   Tue, 12 Jul 2016 16:40:59 +0530

amfnd: donot read configuration for mw comp [#369] Amf shouldn't read
configuration for ncs component. this case is for SU instantiation.


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


Testing Commands:
-
mf-adm lock safSu=SC-2,safSg=NoRed,safApp=OpenSAF
amf-adm lock-in safSu=SC-2,safSg=NoRed,safApp=OpenSAF
amf-adm unlock-in safSu=SC-2,safSg=NoRed,safApp=OpenSAF


Testing, Expected Results:
--
It should succeed.

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.


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


[devel] [PATCH 1 of 1] amfnd: donot read configuration for mw comp [#369]

2016-07-12 Thread nagendra . k
 osaf/services/saf/amf/amfnd/imm.cc |  7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)


Amf shouldn't read configuration for ncs component.
this case is for SU instantiation.

diff --git a/osaf/services/saf/amf/amfnd/imm.cc 
b/osaf/services/saf/amf/amfnd/imm.cc
--- a/osaf/services/saf/amf/amfnd/imm.cc
+++ b/osaf/services/saf/amf/amfnd/imm.cc
@@ -111,7 +111,12 @@ void ImmReader::ir_process_event(AVND_EV
goto done;
}
 
-   res = avnd_comp_config_get_su(su);
+   if(false == su->is_ncs) {
+   res = avnd_comp_config_get_su(su);
+   } else {
+   res = NCSCC_RC_FAILURE;
+   }
+
{
AVND_EVT *evt_ir = 0;
TRACE("Sending to main thread.");

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


[devel] [PATCH 1 of 1] amfd: avoid resetting alarm for duplicate node ups [#1893]

2016-06-23 Thread nagendra . k
 osaf/services/saf/amf/amfd/ndfsm.cc |  12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)


When Amfd receives duplicate node up messages from Act
amfnd, then it tries to reset alarm_sent for SI.
This happens when cluster is recovering from headless state.
And if that happens then when those SIs gets assigned,
then alarms are not reset.
This patch fixes this issue. It avoids resetting alarm_sent
when duplicate node ups are received.

diff --git a/osaf/services/saf/amf/amfd/ndfsm.cc 
b/osaf/services/saf/amf/amfd/ndfsm.cc
--- a/osaf/services/saf/amf/amfd/ndfsm.cc
+++ b/osaf/services/saf/amf/amfd/ndfsm.cc
@@ -51,11 +51,13 @@ void avd_process_state_info_queue(AVD_CL
uint32_t i;
const auto queue_size = cb->evt_queue.size();
AVD_EVT_QUEUE *queue_evt = nullptr;
+   /* Counter for Act Amfnd node up message.*/
+   static int act_amfnd_node_up_count = 0;
 
TRACE_ENTER();
 
TRACE("queue_size before processing: %lu", (unsigned long) queue_size);
-
+   act_amfnd_node_up_count ++;
// recover assignments from state info
for(i=0 ; ievt_queue.front();
@@ -91,6 +93,13 @@ void avd_process_state_info_queue(AVD_CL
}
}
 
+   /* Alarms shouldn't be reset in next subsequent node up message.
+  Because in the previous node up messages queue_size might have
+  been zero. In the subsequent node up messages, this might cause
+  alarm_sent to get reset and this may cause unassigned alarm to
+  exist even those SIs are assigned after some time.*/
+   if (act_amfnd_node_up_count > 1) goto done;
+
// Once active amfd looks up the state info from queue, that means node 
sync
// finishes. Therefore, if the queue is empty, this active amfd is 
coming
// from a cluster restart, the alarm state should be reset.
@@ -115,6 +124,7 @@ void avd_process_state_info_queue(AVD_CL
}
}
}
+done:
TRACE("queue_size after processing: %lu", (unsigned long) 
cb->evt_queue.size());
TRACE_LEAVE();
 }

--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
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: avoid resetting alarm for duplicate node ups [#1893]

2016-06-23 Thread nagendra . k
Summary: amfd: avoid resetting alarm for duplicate node ups [#1893]
Review request for Trac Ticket(s): #1893
Peer Reviewer(s): Amf developers 
Pull request to: <>
Affected branch(es): 5.0 and 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 754ddba41f0ed11af2cf426677fe68dd69ec3b07
Author: Nagendra Kumar
Date:   Thu, 23 Jun 2016 16:13:30 +0530

amfd: avoid resetting alarm for duplicate node ups [#1893] When Amfd
receives duplicate node up messages from Act amfnd, then it tries to 
reset
alarm_sent for SI. This happens when cluster is recovering from headless
state. And if that happens then when those SIs gets assigned, then 
alarms
are not reset. This patch fixes this issue. It avoids resetting 
alarm_sent
when duplicate node ups are received.


Complete diffstat:
--
 osaf/services/saf/amf/amfd/ndfsm.cc |  12 +++-
 1 files changed, 11 insertions(+), 1 deletions(-)


Testing Commands:
-
Please refer the ticket.

Testing, Expected Results:
--
Please refer the ticket.


Conditions of Submission:
-
Ack from Amf Developers.

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.


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfnd: ignore hc expiry in unhealthy state [#1858]

2016-06-01 Thread nagendra . k
 osaf/services/saf/amf/amfnd/chc.cc |  10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)


If the component is not in instantiated state, then hc expiry
should be ignored.

diff --git a/osaf/services/saf/amf/amfnd/chc.cc 
b/osaf/services/saf/amf/amfnd/chc.cc
--- a/osaf/services/saf/amf/amfnd/chc.cc
+++ b/osaf/services/saf/amf/amfnd/chc.cc
@@ -926,6 +926,16 @@ uint32_t avnd_comp_hc_rec_tmr_exp(AVND_C
 
TRACE_ENTER2("%s - %s, sts: %u", comp->name.value, rec->key.key, 
rec->status);
 
+   /* There is a chance that the term command has been issued to comp and
+  the timer has expired and it is in mail box. 
+  So, if the component is not in healthy state, then don't start HC. */
+
+   if (!m_AVND_COMP_PRES_STATE_IS_INSTANTIATED(comp)) {
+   TRACE_1("'%s' not instantiated, not starting HC", 
comp->name.value);
+   rec->status = AVND_COMP_HC_STATUS_STABLE;
+   return rc;
+   }
+
if (m_AVND_COMP_HC_REC_IS_AMF_INITIATED(rec)) {
if (rec->status == AVND_COMP_HC_STATUS_STABLE)
if (comp->is_hc_cmd_configured &&

--
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. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
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: ignore hc expiry in unhealthy state [#1858]

2016-06-01 Thread nagendra . k
Summary: amfnd: ignore hc expiry in unhealthy state [#1858]
Review request for Trac Ticket(s): #1858
Peer Reviewer(s): Amf dev
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 4d25c9a260185b395a5dd9a4a688be6e4a214f22
Author: Nagendra Kumar
Date:   Wed, 01 Jun 2016 17:59:57 +0530

amfnd: ignore hc expiry in unhealthy state [#1858] If the component is 
not
in instantiated state, then hc expiry should be ignored.


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


Testing Commands:
-
Please refer the ticket.

Testing, Expected Results:
--
Please refre the ticket.

Conditions of Submission:
-
Ack

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.


--
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. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: avoid null pointer access [#1823]

2016-05-11 Thread nagendra . k
 osaf/services/saf/amf/amfd/nodegroup.cc |  4 
 1 files changed, 4 insertions(+), 0 deletions(-)


Amfd is crashing because of null pointer acceess.
This can happen if the node is removed from nodegroup
at Act Amfd, but not removed at Standby Amfd.
But node was deleted from both Act and Standby Amfd.

diff --git a/osaf/services/saf/amf/amfd/nodegroup.cc 
b/osaf/services/saf/amf/amfd/nodegroup.cc
--- a/osaf/services/saf/amf/amfd/nodegroup.cc
+++ b/osaf/services/saf/amf/amfd/nodegroup.cc
@@ -467,6 +467,8 @@ static SaAisErrorT ng_ccb_completed_dele
++iter) {
 
node = avd_node_get(*iter);
+   if (node == nullptr)
+   continue;

TRACE("%s", node->name.value);
 
@@ -585,6 +587,8 @@ static void ng_ccb_apply_delete_hdlr(Ccb
for (std::set::const_iterator iter = 
ng->saAmfNGNodeList.begin();
iter != ng->saAmfNGNodeList.end(); ++iter) {
AVD_AVND *node = avd_node_get(*iter);
+   if (node == nullptr)
+   continue;
node->admin_ng = nullptr;
node->su_cnt_admin_oper = 0;
}

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
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: avoid null pointer access [#1823]

2016-05-11 Thread nagendra . k
Summary: amfd: avoid null pointer access [#1823]
Review request for Trac Ticket(s): #1823
Peer Reviewer(s): Amf Developers
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 c27e1d5233f9b3578be789ff20fa14ca1b28
Author: Nagendra Kumar
Date:   Wed, 11 May 2016 14:56:04 +0530

amfd: avoid null pointer access [#1823] Amfd is crashing because of null
pointer acceess. This can happen if the node is removed from nodegroup 
at
Act Amfd, but not removed at Standby Amfd. But node was deleted from 
both
Act and Standby Amfd.


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


Testing Commands:
-
Refre ticket.

Testing, Expected Results:
--
Standby Amfd didn't crash

Conditions of Submission:
-
Ack

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.


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
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: mark su fsm state as assigned [#1756]

2016-04-29 Thread nagendra . k
Summary: amfd: mark su fsm state as assigned [#1756]
Review request for Trac Ticket(s): #1756
Peer Reviewer(s): Amf developers
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 c5881f5b6a13ef45de793fe8cd4ec74e1c09e96e
Author: Nagendra Kumar
Date:   Fri, 29 Apr 2016 16:53:50 +0530

amfd: mark su fsm state as assigned [#1756] During SI shutdown 
operation,
there is chance that this SI will be in unassigned state during si 
delete
and other SIs assigned to the SU will be in assigned state. So, this is 
a
valid combination of fsm state among SUSI at a given point of time. So, 
if
other SIs are in assigned state, mark SU fsm state also in
AVD_SU_SI_STATE_ASGND state.


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


Testing Commands:
-
As per ticket.

Testing, Expected Results:
--
Amfd shouldn't crash and should be able to do SU failover.

Conditions of Submission:
-
Ack

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.


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: mark su fsm state as assigned [#1756]

2016-04-29 Thread nagendra . k
 osaf/services/saf/amf/amfd/sg_2n_fsm.cc |  7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)


During SI shutdown operation, there is chance that this SI
will be in unassigned state during si delete and other SIs assigned
to the SU will be in assigned state. So, this is a valid combination
of fsm state among SUSI at a given point of time.
So, if other SIs are in assigned state, mark SU fsm state also
in AVD_SU_SI_STATE_ASGND state.

diff --git a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc 
b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
--- a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
+++ b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
@@ -116,10 +116,13 @@ AVD_SU_SI_STATE avd_su_fsm_state_determi
   can be in assigned state in transition.*/
fsm_state = AVD_SU_SI_STATE_ASGN;
} else if ((true == unassingned_flag) && (false == assigned_flag)) {
-   /* Rule 2. => If any one of the SUSI is unassigned, then SU 
will be said to be Unassigned.*/
+   /* Rule 3. => If any one of the SUSI is unassigned, then SU 
will be said to be Unassigned.*/
fsm_state = AVD_SU_SI_STATE_UNASGN;
} else if ((true == assigned_flag) && (false == unassingned_flag)) {
-   /* Rule 3. => All are assigned */ 
+   /* Rule 4. => All are assigned */ 
+   fsm_state = AVD_SU_SI_STATE_ASGND;
+   } else if ((true == assigned_flag) && (true == unassingned_flag)) {
+   /* Rule 5. => All are assigned */ 
fsm_state = AVD_SU_SI_STATE_ASGND;
} else {
osafassert(0);

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfnd: process su instantiation in a separate thread [#517]

2016-03-15 Thread nagendra . k
 osaf/services/saf/amf/amfnd/Makefile.am|3 +-
 osaf/services/saf/amf/amfnd/evt.cc |   14 ++-
 osaf/services/saf/amf/amfnd/imm.cc |  137 +
 osaf/services/saf/amf/amfnd/include/avnd.h |6 +
 osaf/services/saf/amf/amfnd/main.cc|3 +-
 5 files changed, 158 insertions(+), 5 deletions(-)


If immnd is down and Amf decides to instantiate some SU, then there
is a deadlock between Amfnd and Imm. Amf calls Imm api to read
imm attributes during SU instantiation and stuck because Imm
is down. Imm waits for Amfnd to instantiate/restart it.
So, both waits for each other. This is a deadlock.
So, the fix bypasses main thread for SU instantiation and does
process of SU instantiation in a separate thread.
So, when Imm is down, its instantiation/restart happens in the
main thread. If any SU instantiation request comes, then Amfnd
routes that request in a separate thread, that threads stuck in Imm
api call untill Imm is not restarted and responds to Imm api call.
This obviates the deadlock between Amfnd and Imm.
So, this fix has advantage for not having any mutex between threads.
The reason is that SU is yet to instantiate, so it is still
immune to faults of any components and hence no need of having any
mutex among the threads.

diff --git a/osaf/services/saf/amf/amfnd/Makefile.am 
b/osaf/services/saf/amf/amfnd/Makefile.am
--- a/osaf/services/saf/amf/amfnd/Makefile.am
+++ b/osaf/services/saf/amf/amfnd/Makefile.am
@@ -60,7 +60,8 @@ osafamfnd_SOURCES = \
term.cc \
tmr.cc \
util.cc \
-   verify.cc 
+   verify.cc \
+   imm.cc
 
 osafamfnd_LDADD = \
$(top_builddir)/osaf/tools/safimm/src/libimmutil.la \
diff --git a/osaf/services/saf/amf/amfnd/evt.cc 
b/osaf/services/saf/amf/amfnd/evt.cc
--- a/osaf/services/saf/amf/amfnd/evt.cc
+++ b/osaf/services/saf/amf/amfnd/evt.cc
@@ -319,9 +319,17 @@ void avnd_evt_destroy(AVND_EVT *evt)
 **/
 uint32_t avnd_evt_send(AVND_CB *cb, AVND_EVT *evt)
 {
-   uint32_t rc = m_NCS_IPC_SEND(>mbx, evt, evt->priority);
-   if (NCSCC_RC_SUCCESS != rc)
-   LOG_CR("AvND send event to mailbox failed, type = %u", 
evt->type);
+   uint32_t rc;
+   if (evt->type == AVND_EVT_AVD_SU_PRES_MSG) {
+   TRACE("AVND_EVT_AVD_REG_SU_MSG");
+   rc = m_NCS_IPC_SEND(_cb.mbx, evt, evt->priority);
+   if (NCSCC_RC_SUCCESS != rc)
+   LOG_CR("AvND send event to mailbox failed, type = %u", 
evt->type);
+   } else {
+   rc = m_NCS_IPC_SEND(>mbx, evt, evt->priority);
+   if (NCSCC_RC_SUCCESS != rc)
+   LOG_CR("AvND send event to mailbox failed, type = %u", 
evt->type);
+   }
 
return rc;
 }
diff --git a/osaf/services/saf/amf/amfnd/imm.cc 
b/osaf/services/saf/amf/amfnd/imm.cc
new file mode 100644
--- /dev/null
+++ b/osaf/services/saf/amf/amfnd/imm.cc
@@ -0,0 +1,137 @@
+/*  -*- OpenSAF  -*-
+ *
+ * (C) Copyright 2016 The OpenSAF Foundation
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. This file and program are licensed
+ * under the GNU Lesser General Public License Version 2.1, February 1999.
+ * The complete license can be accessed from the following location:
+ * http://opensource.org/licenses/lgpl-license.php
+ * See the Copying file included with the OpenSAF distribution for full
+ * licensing terms.
+ *
+ * Author(s): Oracle
+ *
+ */
+
+#include "avnd.h"
+#include 
+
+enum {
+   FD_MBX = 0
+};
+
+ir_cb_t ir_cb;
+
+extern const AVND_EVT_HDLR g_avnd_func_list[AVND_EVT_MAX];
+
+static struct pollfd fds[FD_MBX + 1];
+static nfds_t irfds = FD_MBX + 1;
+static void ir_process_event(AVND_EVT *evt);
+
+/**
+ * This thread will read classes and object information thereby allowing main
+ * thread to proceed with other important work.
+ * As of now, SU instantiation needs imm data to be read, so
+ * only this event is being handled here.
+ * Going forward, we need to use this function for similar purposes.
+ * @param _cb
+ *
+ * @return void*
+ */
+static void *imm_reader_thread(void *_cb)
+{
+   uint32_t rc = SA_AIS_OK;
+   AVND_EVT *evt;
+   TRACE_ENTER();
+   NCS_SEL_OBJ mbx_fd;
+
+   /* create the mail box */
+   rc = m_NCS_IPC_CREATE(_cb.mbx);
+   if (NCSCC_RC_SUCCESS != rc) {
+   LOG_CR("AvND Mailbox creation failed");
+   exit(EXIT_FAILURE);
+   }
+   TRACE("Ir mailbox creation success");
+
+   /* attach the mail box */
+   rc = m_NCS_IPC_ATTACH(_cb.mbx);
+   if (NCSCC_RC_SUCCESS != rc) {
+   LOG_CR("Ir mailbox attach failed");
+   exit(EXIT_FAILURE);
+   }
+
+   mbx_fd = ncs_ipc_get_sel_obj(_cb.mbx);
+   fds[FD_MBX].fd = mbx_fd.rmv_obj;
+   

[devel] [PATCH 0 of 1] Review Request for amfd: delete su and its child objects at stdby amfd [#1683]

2016-02-25 Thread nagendra . k
Summary: amfd: delete su and its child objects at stdby amfd [#1683]
Review request for Trac Ticket(s): #1683
Peer Reviewer(s): Amf maintainers 
Pull request to: <>
Affected branch(es): All
Development branch: 4.7.x


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 339491d8fc5aac772a27f477c3f7d2e676fc6ba5
Author: Nagendra Kumar
Date:   Fri, 26 Feb 2016 12:19:26 +0530

amfd: delete su and its child objects at stdby amfd [#1683] If SUs are
deleted at Act Amfd when Stdby Amfd has finished reading objects from 
Imm
database, Stdby Amfd still has those SUs. Now, if node hosting those 
Sus are
deleted, Act Amfd says Ok, but Stdby Amfd says it still has some SUs 
left on
that node to be deleted. Hence in apply callback, Stdby Amfd crashes. 
So,
this patch makes sure that in this particular scenarios, if node is 
being
deleted and if there are some Sus and its child obkects are still there,
Stdby Amfd deletes them.


Complete diffstat:
--
 osaf/services/saf/amf/amfd/comp.cc|   2 +-
 osaf/services/saf/amf/amfd/include/comp.h |   1 +
 osaf/services/saf/amf/amfd/include/su.h   |   2 +-
 osaf/services/saf/amf/amfd/node.cc|  54 
++
 osaf/services/saf/amf/amfd/su.cc  |   2 +-
 osaf/services/saf/amf/amfd/util.cc|  16 
 6 files changed, 74 insertions(+), 3 deletions(-)


Testing Commands:
-
As per ticket.

Testing, Expected Results:
--
Standby Amfd shouldn't crash.

Conditions of Submission:
-
Ack from 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.


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor 

[devel] [PATCH 1 of 1] amfd: delete su and its child objects at stdby amfd [#1683]

2016-02-25 Thread nagendra . k
 osaf/services/saf/amf/amfd/comp.cc|   2 +-
 osaf/services/saf/amf/amfd/include/comp.h |   1 +
 osaf/services/saf/amf/amfd/include/su.h   |   2 +-
 osaf/services/saf/amf/amfd/node.cc|  54 +++
 osaf/services/saf/amf/amfd/su.cc  |   2 +-
 osaf/services/saf/amf/amfd/util.cc|  16 +
 6 files changed, 74 insertions(+), 3 deletions(-)


If SUs are deleted at Act Amfd when Stdby Amfd has finished
reading objects from Imm database, Stdby Amfd still has those SUs.
Now, if node hosting those Sus are deleted, Act Amfd says Ok, but
Stdby Amfd says it still has some SUs left on that node to be deleted.
Hence in apply callback, Stdby Amfd crashes.
So, this patch makes sure that in this particular scenarios, if
node is being deleted and if there are some Sus and its child obkects
are still there, Stdby Amfd deletes them.

diff --git a/osaf/services/saf/amf/amfd/comp.cc 
b/osaf/services/saf/amf/amfd/comp.cc
--- a/osaf/services/saf/amf/amfd/comp.cc
+++ b/osaf/services/saf/amf/amfd/comp.cc
@@ -1577,7 +1577,7 @@ static void comp_ccb_apply_modify_hdlr(s
TRACE_LEAVE();
 }
 
-static void comp_ccb_apply_delete_hdlr(struct CcbUtilOperationData *opdata)
+void comp_ccb_apply_delete_hdlr(struct CcbUtilOperationData *opdata)
 {
TRACE_ENTER();
 
diff --git a/osaf/services/saf/amf/amfd/include/comp.h 
b/osaf/services/saf/amf/amfd/include/comp.h
--- a/osaf/services/saf/amf/amfd/include/comp.h
+++ b/osaf/services/saf/amf/amfd/include/comp.h
@@ -275,4 +275,5 @@ bool comp_is_preinstantiable(const AVD_C
 extern bool is_comp_assigned_any_csi(AVD_COMP *comp);
 extern SaAisErrorT check_comp_stability(const AVD_COMP*);
 extern AVD_CTCS_TYPE *get_ctcstype(const SaNameT *comptype_name, const SaNameT 
*cstype_name);
+extern void comp_ccb_apply_delete_hdlr(struct CcbUtilOperationData *opdata);
 #endif
diff --git a/osaf/services/saf/amf/amfd/include/su.h 
b/osaf/services/saf/amf/amfd/include/su.h
--- a/osaf/services/saf/amf/amfd/include/su.h
+++ b/osaf/services/saf/amf/amfd/include/su.h
@@ -171,5 +171,5 @@ extern SaAisErrorT avd_su_config_get(con
  * Class constructor, must be called before any other function
  */
 extern void avd_su_constructor(void);
-
+extern void su_ccb_apply_delete_hdlr(struct CcbUtilOperationData *opdata);
 #endif
diff --git a/osaf/services/saf/amf/amfd/node.cc 
b/osaf/services/saf/amf/amfd/node.cc
--- a/osaf/services/saf/amf/amfd/node.cc
+++ b/osaf/services/saf/amf/amfd/node.cc
@@ -165,9 +165,56 @@ AVD_AVND *avd_node_new(const SaNameT *dn
 
 void avd_node_delete(AVD_AVND *node)
 {
+   TRACE_ENTER();
osafassert(node->pg_csi_list.n_nodes == 0);
if (node->node_info.nodeId)
avd_node_delete_nodeid(node);
+   /* Check if the SUs and related objects are still left. This can
+  happen on Standby Amfd when it has just read the configuration
+  and before it becomes applier, Act Amfd deletes SUs. Those SUs
+  will be left out at Standby Amfd. Though this could be rare.*/
+   if (avd_cb->avail_state_avd != SA_AMF_HA_ACTIVE) {
+   if (node->list_of_su.empty() != true) {
+   std::vector *su_list = nullptr;
+   su_list = >list_of_su;
+   std::vector::const_iterator su_iter;
+   for (su_iter = su_list->begin(); su_iter != 
su_list->end(); ) {
+   AVD_SU *su = *su_iter;
+   TRACE("Standby Amfd, su '%s' not deleted", 
su->name.value);
+   std::vector *comp_list = nullptr;
+   comp_list = >list_of_comp;
+   std::vector::const_iterator 
comp_iter;
+   for (comp_iter = comp_list->begin(); comp_iter 
!= comp_list->end(); ) {
+   AVD_COMP *comp = *comp_iter;
+   TRACE("Standby Amfd, comp '%s' not 
deleted", comp->comp_info.name.value);
+   /* Delete the CompCsType. */
+   for (std::map::const_iterator it =
+   compcstype_db->begin();
+   it != 
compcstype_db->end(); it++) {
+   AVD_COMPCS_TYPE *compcstype = 
it->second;
+   if (compcstype->comp == comp) {
+   TRACE("Standby Amfd, 
compcstype '%s' not deleted",
+   
compcstype->name.value);
+   
compcstype_db->erase(Amf::to_string(>name));
+   delete compcstype;
+

[devel] [PATCH 1 of 1] amfnd: delay csi_remove_done for NPI comp [#1862]

2016-02-18 Thread nagendra . k
 osaf/services/saf/amf/amfnd/clc.cc |  8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)


When an Su contains one PI and one NPI comp and if terminate script
of NPI comp returns non-zero, but cleaup script of NPI returns zero,
then during opensafd stop, Amfnd crashes.
The reason is avnd_comp_csi_remove_done is called from 
avnd_comp_clc_terming_cleansucc
and SU-SI is deleted inside. When subsequent function avnd_comp_clc_st_chng_prc 
is called
Amfnd asserts because component doesnt have any csi as it got deleted in
avnd_comp_csi_remove_done.
So, since handling of 'SU Preinst and Comp Non-Preinst' and
'TERMINATING eq prv_st and UNINSTANTIATED eq final_st' are in 
avnd_comp_clc_st_chng_prc
so, better postpone avnd_comp_csi_remove_done to a later stage as it happens in
normal scenarion when terminate script of NPI comp return zero(success).

diff --git a/osaf/services/saf/amf/amfnd/clc.cc 
b/osaf/services/saf/amf/amfnd/clc.cc
--- a/osaf/services/saf/amf/amfnd/clc.cc
+++ b/osaf/services/saf/amf/amfnd/clc.cc
@@ -2159,7 +2159,13 @@ uint32_t avnd_comp_clc_terming_cleansucc
   done indication cannot be generated for 
assigned CSIs. 
 */
if 
(m_AVND_COMP_CSI_CURR_ASSIGN_STATE_IS_REMOVING(csi))
-   rc = avnd_comp_csi_remove_done(cb, 
comp, csi); 
+   /* Csi remove done for PI comp only and 
not for NPI comp in PI SU.
+  When avnd_comp_clc_st_chng_prc will 
be called and it will be a
+  case of "SU Preinst and Comp 
Non-Preinst" and
+  TERMINATING == prv_st and 
UNINSTANTIATED == final_st, then
+  avnd_comp_csi_remove_done will be 
called. */
+   if 
(m_AVND_COMP_TYPE_IS_PREINSTANTIABLE(comp))
+   rc = 
avnd_comp_csi_remove_done(cb, comp, csi); 
 
/* Removal of last CSI from this component may 
lead to SUSI assign/remove 
   done indication, which eventually deletes 
all COMP-CSI record.

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140
___
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: delay csi_remove_done for NPI comp [#1862]

2016-02-18 Thread nagendra . k
Summary: amfnd: delay csi_remove_done for NPI comp [#1862]
Review request for Trac Ticket(s): #1862
Peer Reviewer(s): Amf maintainers
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 31a647aa2a6bc4e9b8be7e0b2b82c58c8814064b
Author: Nagendra Kumar
Date:   Thu, 18 Feb 2016 20:34:59 +0530

amfnd: delay csi_remove_done for NPI comp [#1862] When an Su contains 
one PI
and one NPI comp and if terminate script of NPI comp returns non-zero, 
but
cleaup script of NPI returns zero, then during opensafd stop, Amfnd 
crashes.
The reason is avnd_comp_csi_remove_done is called from
avnd_comp_clc_terming_cleansucc and SU-SI is deleted inside. When 
subsequent
function avnd_comp_clc_st_chng_prc is called Amfnd asserts because 
component
doesnt have any csi as it got deleted in avnd_comp_csi_remove_done. So,
since handling of 'SU Preinst and Comp Non-Preinst' and 'TERMINATING eq
prv_st and UNINSTANTIATED eq final_st' are in avnd_comp_clc_st_chng_prc 
so,
better postpone avnd_comp_csi_remove_done to a later stage as it 
happens in
normal scenarion when terminate script of NPI comp return zero(success).


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


Testing Commands:
-
As per ticket

Testing, Expected Results:
--
Amfnd shouldn't crash

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.


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and 

[devel] [PATCH 1 of 1] amfd: act amfd allows cold sync after it reads config [#1603]

2015-11-22 Thread nagendra . k
 osaf/services/saf/amf/amfd/chkop.cc |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


When cold sync req reaches Act Amfd and when its state is in AVD_CFG_DONE,
it returns NCSCC_RC_FAILURE to Mbcsv. Mbcsv doesn't respond back to
its Standby peer that Cold sync has failed. Act Mbcsv peer waits till
Cold sync timer NCS_MBCSV_TMR_SEND_COLD_SYNC_PERIOD (9 Secs).
After this timer expires, Standby Mbcsv peer resends the request, this
time Act Amfd is in AVD_INIT_DONE and hence Cold sync starts.
This is the reason for 9 Seconds delay reported in the ticket.

Amfd can start Cold sync even it has read the configuration
and it need not wait the Act controller to come up fully.
That means, Amfd need not wait till m/w susi is assigned on
Act controller. Because, for Standby SUSI to get assigned,
Amfd should be in AVD_INIT_DONE, so this avoids, Standby Controller
taking Act role (2N M/w susi).
So, the fix paces up Cold sync to start.

diff --git a/osaf/services/saf/amf/amfd/chkop.cc 
b/osaf/services/saf/amf/amfd/chkop.cc
--- a/osaf/services/saf/amf/amfd/chkop.cc
+++ b/osaf/services/saf/amf/amfd/chkop.cc
@@ -405,7 +405,7 @@ ignore_msg:
 */
TRACE("COLD_SYNC_REQ");
 
-   if (cb->init_state < AVD_INIT_DONE) {
+   if (cb->init_state < AVD_CFG_DONE) {
TRACE("invalid init state (%u) for cold sync 
req", cb->init_state);
status = NCSCC_RC_FAILURE;
}

--
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741551=/4140
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: set node oper state to enable during clm unlock [#1567]

2015-11-02 Thread nagendra . k
 osaf/services/saf/amf/amfd/clm.cc   |  4 +++-
 osaf/services/saf/amf/amfd/nodegroup.cc |  7 ---
 2 files changed, 7 insertions(+), 4 deletions(-)


During Clm unlock, Amf is not marking node oper state to enable,
if that node admin state is in locked-in state.
Ideally, in cany case, Amf need to mark the state to enable when
the node joins the Cluster i.e. clm unlock.
The other fix is to check the node oper state while
sending SU pres message to Amfnd.
Change of 'node->' to 'su->su_on_node->' is a refactoring correction.

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
@@ -27,6 +27,9 @@ static SaVersionT clmVersion = { 'B', 4,
 static void clm_node_join_complete(AVD_AVND *node)
 {
TRACE_ENTER();
+   /* Enable the node in any case. */
+   avd_node_oper_state_set(node, SA_AMF_OPERATIONAL_ENABLED);
+
/* For each of the SUs calculate the readiness state. 
 ** call the SG FSM with the new readiness state.
 */
@@ -36,7 +39,6 @@ static void clm_node_join_complete(AVD_A
goto done;
}
 
-   avd_node_oper_state_set(node, SA_AMF_OPERATIONAL_ENABLED);
for (const auto& su : node->list_of_su) {
/* For non-preinstantiable SU unlock-inst will not lead to its 
inst until unlock. */
if ( su->saAmfSUPreInstantiable == false ) {
diff --git a/osaf/services/saf/amf/amfd/nodegroup.cc 
b/osaf/services/saf/amf/amfd/nodegroup.cc
--- a/osaf/services/saf/amf/amfd/nodegroup.cc
+++ b/osaf/services/saf/amf/amfd/nodegroup.cc
@@ -914,11 +914,12 @@ static void ng_admin_unlock_inst(AVD_AMF
continue;
 
if ((su->saAmfSUAdminState != 
SA_AMF_ADMIN_LOCKED_INSTANTIATION) &&
-   (node->saAmfNodeAdminState != 
SA_AMF_ADMIN_LOCKED_INSTANTIATION) &&
+   
(su->su_on_node->saAmfNodeAdminState != SA_AMF_ADMIN_LOCKED_INSTANTIATION) &&
(su->saAmfSUOperState == 
SA_AMF_OPERATIONAL_ENABLED) &&
-   (su->saAmfSUPresenceState == 
SA_AMF_PRESENCE_UNINSTANTIATED)) {
+   (su->saAmfSUPresenceState == 
SA_AMF_PRESENCE_UNINSTANTIATED) &&
+   
(su->su_on_node->saAmfNodeOperState == SA_AMF_OPERATIONAL_ENABLED)) {
if ((su->saAmfSUPreInstantiable == 
false) ||
-   (node->node_state != 
AVD_AVND_STATE_PRESENT))
+   
(su->su_on_node->node_state != AVD_AVND_STATE_PRESENT))
continue;
 
if (sg->saAmfSGNumPrefInserviceSUs > 
su_try_inst) {

--
___
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: check for admin state for all nodegroup [#1563]

2015-10-30 Thread nagendra . k
Summary: amfd: check for admin state for all nodegroup [#1563]
Review request for Trac Ticket(s): #1563
Peer Reviewer(s): hans.nordeb...@ericsson.com, praveen.malv...@oracle.com
Pull request to: <>
Affected branch(es): 6.6, 6.7, 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 718ccfea42cdea8d84c4c017e7e9bbc87b5aceb9
Author: Nagendra Kumar
Date:   Fri, 30 Oct 2015 18:18:41 +0530

amfd: check for admin state for all nodegroup [#1563] Amf is not 
checking
admin state for all the node groups to which a node belongs to during
nodegroup unlock-in. Ideally, if one of the nodegroup of a node is in
locked-in, Amf shouldn't instantiate the SUs on that node if another
nodegroup of that node is being unlocked-in.


Complete diffstat:
--
 osaf/services/saf/amf/amfd/node.cc  |  6 --
 osaf/services/saf/amf/amfd/nodegroup.cc |  4 
 2 files changed, 8 insertions(+), 2 deletions(-)


Testing Commands:
-
Start single controller with Amf demo and run the below command:
1.
amf-adm lock safAmfNodeGroup=SCs,safAmfCluster=myAmfCluster
amf-adm lock-in  safAmfNodeGroup=SCs,safAmfCluster=myAmfCluster
amf-adm lock  safAmfNodeGroup=AllNodes,safAmfCluster=myAmfCluster
amf-adm lock-in   safAmfNodeGroup=AllNodes,safAmfCluster=myAmfCluster
immcfg -f  /tmp/AppConfig-2N.xml
amf-adm  unlock-in safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1
amf-adm  unlock safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1
amf-adm unlock-in   safAmfNodeGroup=AllNodes,safAmfCluster=myAmfCluster
2. 
amf-adm unlock-in   safAmfNodeGroup=SCs,safAmfCluster=myAmfCluster
3.
amf-adm lock-in   safAmfNodeGroup=AllNodes,safAmfCluster=myAmfCluster
amf-adm lock-in   safAmfNodeGroup=SCs,safAmfCluster=myAmfCluster
amf-adm unlock-in   safAmfNodeGroup=SCs,safAmfCluster=myAmfCluster
4.
amf-adm unlock-in   safAmfNodeGroup=AllNodes,safAmfCluster=myAmfCluster

Testing, Expected Results:
--
1. SU should not be instantiated.
2. SU is instantiated on SC-1.
3. Sus are terminated and then Sus are not instantiated.
4. Sus are instantiated.

Conditions of Submission:
-
Ack

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; 

[devel] [PATCH 1 of 1] amfd: check for admin state for all nodegroup [#1563]

2015-10-30 Thread nagendra . k
 osaf/services/saf/amf/amfd/node.cc  |  6 --
 osaf/services/saf/amf/amfd/nodegroup.cc |  4 
 2 files changed, 8 insertions(+), 2 deletions(-)


Amf is not checking admin state for all the node groups to
which a node belongs to during nodegroup unlock-in.
Ideally, if one of the nodegroup of a node is in locked-in, Amf
shouldn't instantiate the SUs on that node if another nodegroup
of that node is being unlocked-in.

diff --git a/osaf/services/saf/amf/amfd/node.cc 
b/osaf/services/saf/amf/amfd/node.cc
--- a/osaf/services/saf/amf/amfd/node.cc
+++ b/osaf/services/saf/amf/amfd/node.cc
@@ -1479,8 +1479,10 @@ bool any_ng_in_locked_in_state(const AVD
 it != nodegroup_db->end(); it++) {
 AVD_AMF_NG *ng = it->second;
 if ((node_in_nodegroup(Amf::to_string(>name), ng) == 
true) &&
-(ng->saAmfNGAdminState == 
SA_AMF_ADMIN_LOCKED_INSTANTIATION))
-return true;
+   (ng->saAmfNGAdminState == 
SA_AMF_ADMIN_LOCKED_INSTANTIATION)) {
+   TRACE("Nodegroup '%s' is in locked-in", ng->name.value);
+   return true;
+   }
 }
 return false;
 }
diff --git a/osaf/services/saf/amf/amfd/nodegroup.cc 
b/osaf/services/saf/amf/amfd/nodegroup.cc
--- a/osaf/services/saf/amf/amfd/nodegroup.cc
+++ b/osaf/services/saf/amf/amfd/nodegroup.cc
@@ -892,6 +892,10 @@ static void ng_admin_unlock_inst(AVD_AMF
LOG_NO("'%s' UNLOCK_INSTANTIATION: AMF node oper state 
disabled", node->name.value);
continue;
}
+   if (any_ng_in_locked_in_state(node) == true) {
+   LOG_NO("One of the node group of '%s' is in locked-in", 
node->name.value);
+   continue;
+   }
for (const auto& node_su : node->list_of_su) {
/*Instantiate only those SUs in this SG which are 
hosted on the Nodes of NG.
   Also honor saAmfSURank while instantating.

--
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: return BAD OP in fault cases during si swap [#1294]

2015-10-14 Thread nagendra . k
 osaf/services/saf/amf/amfd/include/si.h   |1 +
 osaf/services/saf/amf/amfd/sg_2n_fsm.cc   |   67 +--
 osaf/services/saf/amf/amfd/sg_nway_fsm.cc |   31 +
 osaf/services/saf/amf/amfd/si.cc  |  191 ++
 4 files changed, 194 insertions(+), 96 deletions(-)


Return SA_AIS_ERR_BAD_OPERATION for SI SWAP admin op when
1. SI is locked.
2. Only one SU is configured.
3. None of other SUs or its hosting nodes are in unlocked state.
4. All other nodes hosting SUs are down.
5. Other SUs are in inst/term failed state or Out of service.

Return SA_AIS_ERR_TRY_AGAIN  for SI SWAP admin op when
1. Only one assignment for M/w SI. This is in assumption that
the another controller will come and join shortly.
2. If nodes hosting other unlocked SUs are joining.
3. If other SUs are in INSTANTIATING/TERMINATING/RESTARTING state.

diff --git a/osaf/services/saf/amf/amfd/include/si.h 
b/osaf/services/saf/amf/amfd/include/si.h
--- a/osaf/services/saf/amf/amfd/include/si.h
+++ b/osaf/services/saf/amf/amfd/include/si.h
@@ -141,6 +141,7 @@ public:
bool is_sirank_valid(uint32_t newSiRank) const;
void update_sirank(uint32_t newSiRank);
bool si_dep_states_check();
+   SaAisErrorT si_swap_validate();
 private:
AVD_SI(const AVD_SI&);
AVD_SI& operator=(const AVD_SI&);
diff --git a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc 
b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
--- a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
+++ b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
@@ -736,67 +736,11 @@ done:
 SaAisErrorT SG_2N::si_swap(AVD_SI *si, SaInvocationT invocation) {
AVD_SU_SI_REL *susi;
SaAisErrorT rc = SA_AIS_OK;
-AVD_AVND *node;
 
TRACE_ENTER2("'%s' sg_fsm_state=%u", si->name.value, 
si->sg_of_si->sg_fsm_state);
 
-   if (si->saAmfSIAdminState != SA_AMF_ADMIN_UNLOCKED) {
-   LOG_ER("%s SWAP failed - wrong admin state=%u", si->name.value,
-   si->saAmfSIAdminState);
-   rc = SA_AIS_ERR_TRY_AGAIN;
+   if ((rc = si->si_swap_validate()) != SA_AIS_OK)
goto done;
-   }
-
-   if (avd_cb->init_state != AVD_APP_STATE) {
-   LOG_ER("%s SWAP failed - not in app state (%u)", si->name.value,
-   avd_cb->init_state);
-   rc = SA_AIS_ERR_TRY_AGAIN;
-   goto done;
-   }
-
-   if (si->sg_of_si->sg_fsm_state != AVD_SG_FSM_STABLE) {
-   LOG_ER("%s SWAP failed - SG not stable (%u)", si->name.value,
-   si->sg_of_si->sg_fsm_state);
-   rc = SA_AIS_ERR_TRY_AGAIN;
-   goto done;
-   }
-
-   if (si->list_of_sisu == NULL) {
-   LOG_ER("%s SWAP failed - no assignments to swap", 
si->name.value);
-   rc = SA_AIS_ERR_BAD_OPERATION;
-   goto done;
-   }
-
-   if (si->sg_of_si->sg_ncs_spec) {
-   if (avd_cb->stby_sync_state == AVD_STBY_OUT_OF_SYNC) {
-   LOG_ER("%s SWAP failed - Cold sync in progress", 
si->name.value);
-   rc = SA_AIS_ERR_TRY_AGAIN;
-   goto done;
-   }
-   }
-
-   if (si->list_of_sisu->si_next == NULL) {
-   LOG_ER("%s SWAP failed - only one assignment", si->name.value);
-   rc = SA_AIS_ERR_TRY_AGAIN;
-   goto done;
-   }
-
-   /* Since middleware components can still have si->list_of_sisu->si_next 
as not NULL, but we need to check
-   whether it is unlocked. We need to reject si_swap on controllers when 
stdby controller is locked. */
-   if (si->sg_of_si->sg_ncs_spec) {
-   /* Check if the Standby is there in unlocked state. */
-   node = avd_node_find_nodeid(avd_cb->node_id_avd_other);
-   if (node == NULL) {
-   LOG_NO("SI Swap not possible, node %x is not 
available", avd_cb->node_id_avd_other);
-   rc = SA_AIS_ERR_BAD_OPERATION;
-   goto done;
-   }
-   if (SA_FALSE == node->node_info.member) {
-   LOG_NO("SI Swap not possible, node %x is locked", 
avd_cb->node_id_avd_other);
-   rc = SA_AIS_ERR_BAD_OPERATION;
-   goto done;
-   }
-   }
 
/* Identify the active susi rel */
if (si->list_of_sisu->state == SA_AMF_HA_ACTIVE) {
@@ -809,15 +753,6 @@ SaAisErrorT SG_2N::si_swap(AVD_SI *si, S
goto done;
}
 
-   /* If the swap is on m/w si, then check whether any ccb was going on. */
-   if (si->sg_of_si->sg_ncs_spec) {
-   if (ccbutil_EmptyCcbExists() == false) {
-   rc = SA_AIS_ERR_TRY_AGAIN;
-   LOG_NO("%s SWAP failed - Ccb going on", si->name.value);
-   goto done;
-   }
-   }
-
/* Check if there is dependency between SI's 

[devel] [PATCH 0 of 1] Review Request for amfnd: reset term_cbq_inv_value in finalize call [#1505]

2015-09-28 Thread nagendra . k
Summary: amfnd: reset term_cbq_inv_value in finalize call [#1505]
Review request for Trac Ticket(s): #1505
Peer Reviewer(s): Praveen, Hans N 
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 ffc4e3cf0a60b5220abc86341dbbb41f26658818
Author: Nagendra Kumar
Date:   Mon, 28 Sep 2015 12:43:21 +0530

amfnd: reset term_cbq_inv_value in finalize call [#1505] When called
finalize in term callback, the term_cbq_inv_value is not reset. So, 
when the
component is killed later on, then from avnd_evt_mds_ava_dn_evh, the
recovery is bypassed because of term_cbq_inv_value is set. This patch 
resets
term_cbq_inv_value during finalize call.


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


Testing Commands:
-
As per ticket.

Testing, Expected Results:
--
The comp recovery should be taken.

Conditions of Submission:
-
Ack from maintainsers.

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.


--
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfnd: reset term_cbq_inv_value in finalize call [#1505]

2015-09-28 Thread nagendra . k
 osaf/services/saf/amf/amfnd/comp.cc |  15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)


When called finalize in term callback, the term_cbq_inv_value is not reset. So,
when the component is killed later on, then from avnd_evt_mds_ava_dn_evh, the
recovery is bypassed because of term_cbq_inv_value is set.
This patch resets term_cbq_inv_value during finalize call.

diff --git a/osaf/services/saf/amf/amfnd/comp.cc 
b/osaf/services/saf/amf/amfnd/comp.cc
--- a/osaf/services/saf/amf/amfnd/comp.cc
+++ b/osaf/services/saf/amf/amfnd/comp.cc
@@ -82,6 +82,21 @@ uint32_t avnd_evt_ava_finalize_evh(AVND_
goto done;
}
 
+   /* If Amf was waiting for down event to come regarding term cbq, but
+  finalize has come, so reset the variable (irrespective of Sa-Aware
+  PI or Proxied PI) and proceed for finalize. */
+
+   if (comp->term_cbq_inv_value != 0) {
+   AVND_COMP_CBK *cbk_rec;
+   /* Amf was waiting for this down event. Get the matching
+  entry from the cbk list and delete the cbq */
+   m_AVND_COMP_CBQ_INV_GET(comp, comp->term_cbq_inv_value, 
cbk_rec);
+   comp->term_cbq_inv_value = 0;
+   rc = avnd_comp_clc_fsm_run(cb, comp, 
AVND_COMP_CLC_PRES_FSM_EV_TERM_SUCC);
+   if (cbk_rec)
+   avnd_comp_cbq_rec_pop_and_del(cb, comp, cbk_rec, false);
+   }
+
/* npi comps dont interact with amf */
if (!m_AVND_COMP_TYPE_IS_PREINSTANTIABLE(comp) && 
!m_AVND_COMP_TYPE_IS_PROXIED(comp))
goto done;

--
___
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: correct logic in si dep flow [#276]

2015-08-26 Thread nagendra . k
Summary: amfd: correct logic in si dep flow [#276]
Review request for Trac Ticket(s): #276
Peer Reviewer(s): Praveen, Hans N, Minh, Gary 
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
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):
-
I am still testing it. I am floating it for early
review because this looks only some
logic correction and could be ok to review
just the code.

changeset 6ccb01038db382e520484eebfbbfe9b3b4bdc9c6
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Wed, 26 Aug 2015 11:44:50 +0530

amfd: correct logic in si dep flow [#276] At many places, there has been
tautological errors in si dep flow. The fix corrects them


Complete diffstat:
--
 osaf/services/saf/amf/amfd/si_dep.cc |  25 -
 1 files changed, 12 insertions(+), 13 deletions(-)


Testing Commands:
-
Started system controller.

Testing, Expected Results:
--
No errors.

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


--
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: correct logic in si dep flow [#276]

2015-08-26 Thread nagendra . k
 osaf/services/saf/amf/amfd/si_dep.cc |  25 -
 1 files changed, 12 insertions(+), 13 deletions(-)


At many places, there has been tautological errors in si dep flow.
The fix corrects them

diff --git a/osaf/services/saf/amf/amfd/si_dep.cc 
b/osaf/services/saf/amf/amfd/si_dep.cc
--- a/osaf/services/saf/amf/amfd/si_dep.cc
+++ b/osaf/services/saf/amf/amfd/si_dep.cc
@@ -1468,10 +1468,10 @@ void avd_sidep_unassign_dependents(AVD_S
if 
(m_NCS_MDS_DEST_EQUAL(sisu-su-su_on_node-adest,su-su_on_node-adest)) {
avd_si_unassign(dep_si);
} else {
-   if((dep_si-si_dep_state != AVD_SI_TOL_TIMER_RUNNING) ||
-   (dep_si-si_dep_state != 
AVD_SI_READY_TO_UNASSIGN)) {
+   /* Don't start tol timer if dep state are either in 
running or unassigned. */
+   if(!((dep_si-si_dep_state == AVD_SI_TOL_TIMER_RUNNING) 
||
+   (dep_si-si_dep_state == 
AVD_SI_READY_TO_UNASSIGN))) {

avd_sidep_start_tolerance_timer_for_dependant(dep_si, si);
-
}
}
/* If this dependent SI is sponsor too, then unassign its 
dependents also */
@@ -1788,9 +1788,9 @@ void avd_sidep_update_depstate_si_failov
 
if(su-su_on_node-saAmfNodeOperState == 
SA_AMF_OPERATIONAL_DISABLED) {
if 
((m_NCS_MDS_DEST_EQUAL(sisu-su-su_on_node-adest,su-su_on_node-adest))) {
-   if(((dep_si-si_dep_state != 
AVD_SI_TOL_TIMER_RUNNING) ||
-   (dep_si-si_dep_state 
!= AVD_SI_READY_TO_UNASSIGN) ||
-   (dep_si-si_dep_state 
!= AVD_SI_FAILOVER_UNDER_PROGRESS)) 
+   if((!((dep_si-si_dep_state == 
AVD_SI_TOL_TIMER_RUNNING) ||
+   (dep_si-si_dep_state 
== AVD_SI_READY_TO_UNASSIGN) ||
+   (dep_si-si_dep_state 
== AVD_SI_FAILOVER_UNDER_PROGRESS))) 

(avd_sidep_sponsors_assignment_states(dep_si))) {
 

avd_sidep_si_dep_state_set(dep_si, AVD_SI_FAILOVER_UNDER_PROGRESS);
@@ -1801,10 +1801,9 @@ void avd_sidep_update_depstate_si_failov
}
}
} else if (dep_si-sg_of_si == si-sg_of_si) {
-   if((dep_si-si_dep_state != 
AVD_SI_TOL_TIMER_RUNNING) ||
-   (dep_si-si_dep_state != 
AVD_SI_READY_TO_UNASSIGN) ||
-   (dep_si-si_dep_state != 
AVD_SI_FAILOVER_UNDER_PROGRESS)) {
-
+   if(!((dep_si-si_dep_state == 
AVD_SI_TOL_TIMER_RUNNING) ||
+   (dep_si-si_dep_state == 
AVD_SI_READY_TO_UNASSIGN) ||
+   (dep_si-si_dep_state == 
AVD_SI_FAILOVER_UNDER_PROGRESS))) {

avd_sidep_si_dep_state_set(dep_si, AVD_SI_FAILOVER_UNDER_PROGRESS);
if (dep_si-num_dependents  0) 
{
/* This SI also has 
dependents under it, update their state also */
@@ -1842,9 +1841,9 @@ void avd_sidep_update_depstate_si_failov
}
if (sponsor_assignments_state 
== true) {
 
-   
if((dep_si-si_dep_state != AVD_SI_TOL_TIMER_RUNNING) ||
-  
(dep_si-si_dep_state != AVD_SI_READY_TO_UNASSIGN) ||
-  
(dep_si-si_dep_state != AVD_SI_FAILOVER_UNDER_PROGRESS)) {
+   
if(!((dep_si-si_dep_state == AVD_SI_TOL_TIMER_RUNNING) ||
+  
(dep_si-si_dep_state == AVD_SI_READY_TO_UNASSIGN) ||
+  
(dep_si-si_dep_state == AVD_SI_FAILOVER_UNDER_PROGRESS))) {
 

avd_sidep_si_dep_state_set(dep_si, AVD_SI_FAILOVER_UNDER_PROGRESS);
if 
(dep_si-num_dependents  0) {

--
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net

[devel] [PATCH 0 of 1] Review Request for amfa: return NOT_SUPPORTED for PM_ABNORMAL_END [#181]

2015-08-25 Thread nagendra . k
Summary: amfa: return NOT_SUPPORTED for PM_ABNORMAL_END [#181]
Review request for Trac Ticket(s): #181
Peer Reviewer(s): Praveen, Hans N
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset b7d495faec01256b24916a1b7df5ffc0b28a
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Wed, 26 Aug 2015 10:40:00 +0530

amfa: return NOT_SUPPORTED for PM_ABNORMAL_END [#181] Amf is returning
SA_AIS_ERR_INVALID_PARAM for SA_AMF_PM_ABNORMAL_END and its combination 
with
other SaAmfPmErrorsT flags. This is incorrect behaviour because
SA_AMF_PM_ABNORMAL_END and its combination with other SaAmfPmErrorsT 
flags
are valid input to APIs saAmfPmStart and saAmfPmStop. Since these
combinations feature is not supported in Amf as of now, so, Amf should
return SA_AIS_ERR_NOT_SUPPORTED for such combinations. The fix provides 
the
same.


Complete diffstat:
--
 osaf/libs/agents/saf/amfa/ava_api.c |  28 ++--
 1 files changed, 22 insertions(+), 6 deletions(-)


Testing Commands:
-
Start amf demo appl with saAmfPmStart and saAmfPmStop.
1. Pass pmErr as 1, 2, 3 in saAmfPmStart(Combination of 
SA_AMF_PM_NON_ZERO_EXIT, SA_AMF_PM_ZERO_EXIT).
2. Pass pmErr as 4, 5, 6, 7 in saAmfPmStart(Combination of 
SA_AMF_PM_NON_ZERO_EXIT,
SA_AMF_PM_ZERO_EXIT and SA_AMF_PM_ABNORMAL_END).
3. Pass pmErr as 8, 10, 16 in saAmfPmStart(Some random values).
4. Perform #1, #2, #3 test cases for saAmfPmStart_3(It needs some modification 
in demo code for using B4.1 API).
5. Perform #1, #2, #3 test cases for saAmfPmStop.

Testing, Expected Results:
--
1. Return value is 1(SA_AIS_OK).
2. Return value is 19(SA_AIS_ERR_NOT_SUPPORTED).
3. Return value is 7(SA_AIS_ERR_INVALID_PARAM).
3. Same result as #1, #2, #3.
4. Same result as #1, #2, #3.

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

[devel] [PATCH 1 of 1] amfa: return NOT_SUPPORTED for PM_ABNORMAL_END [#181]

2015-08-25 Thread nagendra . k
 osaf/libs/agents/saf/amfa/ava_api.c |  28 ++--
 1 files changed, 22 insertions(+), 6 deletions(-)


Amf is returning SA_AIS_ERR_INVALID_PARAM for SA_AMF_PM_ABNORMAL_END and its
combination with other SaAmfPmErrorsT flags. This is incorrect behaviour
because SA_AMF_PM_ABNORMAL_END and its combination with other SaAmfPmErrorsT
flags are valid input to APIs saAmfPmStart and saAmfPmStop.
Since these combinations feature is not supported in Amf as of now,
so, Amf should return SA_AIS_ERR_NOT_SUPPORTED for such
combinations.
The fix provides the same.

diff --git a/osaf/libs/agents/saf/amfa/ava_api.c 
b/osaf/libs/agents/saf/amfa/ava_api.c
--- a/osaf/libs/agents/saf/amfa/ava_api.c
+++ b/osaf/libs/agents/saf/amfa/ava_api.c
@@ -953,9 +953,17 @@ SaAisErrorT saAmfPmStart(SaAmfHandleT hd
 
/* input validation of pmError */
if (pmErr != SA_AMF_PM_NON_ZERO_EXIT  pmErr != SA_AMF_PM_ZERO_EXIT 
-   pmErr != (SA_AMF_PM_NON_ZERO_EXIT | SA_AMF_PM_ZERO_EXIT)) {
-   TRACE_LEAVE2(Incorrect argument specified for SaAmfPmErrorsT 
);
-   return SA_AIS_ERR_INVALID_PARAM;
+   pmErr != (SA_AMF_PM_NON_ZERO_EXIT | 
SA_AMF_PM_ZERO_EXIT)) {
+   if ((pmErr == SA_AMF_PM_ABNORMAL_END) ||
+   (pmErr == (SA_AMF_PM_NON_ZERO_EXIT | 
SA_AMF_PM_ABNORMAL_END)) ||
+   (pmErr == (SA_AMF_PM_ZERO_EXIT | 
SA_AMF_PM_ABNORMAL_END)) ||
+   (pmErr == (SA_AMF_PM_ZERO_EXIT | 
SA_AMF_PM_NON_ZERO_EXIT | SA_AMF_PM_ABNORMAL_END))) {
+   TRACE_LEAVE2(Unsupported argument specified for 
SaAmfPmErrorsT );
+   return SA_AIS_ERR_NOT_SUPPORTED;
+   } else {
+   TRACE_LEAVE2(Incorrect argument specified for 
SaAmfPmErrorsT );
+   return SA_AIS_ERR_INVALID_PARAM;
+   }
}
 
/* input validation of Recomended recovery */
@@ -1064,9 +1072,17 @@ SaAisErrorT saAmfPmStop(SaAmfHandleT hdl
 
/* input validation of pmError */
if (pmErr != SA_AMF_PM_NON_ZERO_EXIT  pmErr != SA_AMF_PM_ZERO_EXIT 
-   pmErr != (SA_AMF_PM_NON_ZERO_EXIT | SA_AMF_PM_ZERO_EXIT)) {
-   TRACE_LEAVE2(Incorrect argument specified for SaAmfPmErrorsT);
-   return SA_AIS_ERR_INVALID_PARAM;
+   pmErr != (SA_AMF_PM_NON_ZERO_EXIT | 
SA_AMF_PM_ZERO_EXIT)) {
+   if ((pmErr == SA_AMF_PM_ABNORMAL_END) ||
+   (pmErr == (SA_AMF_PM_NON_ZERO_EXIT | 
SA_AMF_PM_ABNORMAL_END)) ||
+   (pmErr == (SA_AMF_PM_ZERO_EXIT | 
SA_AMF_PM_ABNORMAL_END)) ||
+   (pmErr == (SA_AMF_PM_ZERO_EXIT | 
SA_AMF_PM_NON_ZERO_EXIT | SA_AMF_PM_ABNORMAL_END))) {
+   TRACE_LEAVE2(Unsupported argument specified for 
SaAmfPmErrorsT );
+   return SA_AIS_ERR_NOT_SUPPORTED;
+   } else {
+   TRACE_LEAVE2(Incorrect argument specified for 
SaAmfPmErrorsT);
+   return SA_AIS_ERR_INVALID_PARAM;
+   }
}
 
/* input validation of Process ID */

--
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfnd: send csi remove information in pg cbk [#173]

2015-07-08 Thread nagendra . k
 osaf/services/saf/amf/amfnd/pg.cc |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


During Act SU lock, Amf is not sending information
about csi remove.
Ideally, it should send numberOfItems as 1 and fill
CompName, haState and membership change.

diff --git a/osaf/services/saf/amf/amfnd/pg.cc 
b/osaf/services/saf/amf/amfnd/pg.cc
--- a/osaf/services/saf/amf/amfnd/pg.cc
+++ b/osaf/services/saf/amf/amfnd/pg.cc
@@ -738,7 +738,7 @@ uint32_t avnd_pg_cbk_send(AVND_CB *cb, A
 */
if (true == pg-is_exist) {
/* = this csi exists... invoke the cbk as per the track flags 
*/
-   if ((m_AVND_PG_TRK_IS_CURRENT(trk) || 
m_AVND_PG_TRK_IS_CHANGES(trk))  (pg_param-mem_num)) {
+   if ((m_AVND_PG_TRK_IS_CURRENT(trk) || 
m_AVND_PG_TRK_IS_CHANGES(trk))) {
 /*** include all the current members ***/
 
/* we need to include the comp which just got removed 
from group */

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
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: log about invalid configuration of saAmfSGNumPrefActiveSUs/StandbySUs [#296]

2015-07-02 Thread nagendra . k
Summary: amfd: log about invalid configuration of 
saAmfSGNumPrefActiveSUs/StandbySUs [#296]
Review request for Trac Ticket(s): #296
Peer Reviewer(s): Praveen, Hans N
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset b96305e3c94daa8eeb0af734daa961eed6406c1f
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Thu, 02 Jul 2015 13:44:30 +0530

amfd: log about invalid configuration of 
saAmfSGNumPrefActiveSUs/StandbySUs
[#296] For NpM, saAmfSGNumPrefActiveSUs and saAmfSGNumPrefStandbySUs are
mandatory attributes to configure. Specs states that there should not 
be any
default values for these attributes. But in existing code, we are 
marking
them to 1. If we keep check and reject the configuration without
saAmfSGNumPrefActiveSUs and saAmfSGNumPrefStandbySUs, then there may be
backward compatibility issue. So, in the fix, we just added logs stating
that these configurations are missing. If they are missing, we are 
setting
the values to 1. But for NpM, setting them to 1 means configuration is
almost equivalent to 2N. So, the fix also throws notice that, setting 
them
to 1 is of not much use.


Complete diffstat:
--
 osaf/services/saf/amf/amfd/sg.cc |  26 +-
 1 files changed, 21 insertions(+), 5 deletions(-)


Testing Commands:
-
1. Start SC-1 and upload Amf demo with saAmfSgtRedundancyModel as 2(NpM) and
   without configuring saAmfSGNumPrefActiveSUs and saAmfSGNumPrefStandbySUs.
2. Start SC-1 and upload Amf demo with saAmfSgtRedundancyModel as 2(NpM) and
   with saAmfSGNumPrefActiveSUs as 10 and without configuring 
saAmfSGNumPrefStandbySUs.
3. Start SC-1 and upload Amf demo with saAmfSgtRedundancyModel as 2(NpM) and
   with saAmfSGNumPrefStandbySUs as 10 and without configuring 
saAmfSGNumPrefActiveSUs.
4. Start SC-1 and upload Amf demo with saAmfSgtRedundancyModel as 2(NpM) and
   with configuring saAmfSGNumPrefActiveSUs(10) and 
saAmfSGNumPrefStandbySUs(10).
5. Start SC-1 and upload Amf demo with saAmfSgtRedundancyModel as 1(2N) and
   with saAmfSGNumPrefStandbySUs as 10 and without configuring 
saAmfSGNumPrefActiveSUs.


Testing, Expected Results:
--
In all the cases, CCB will be committed.
1. The following log will come:
osafamfd[16914]: NO 'saAmfSGNumPrefActiveSUs' is set to 1, not useful for NpM
osafamfd[16914]: NO 'saAmfSGNumPrefStandbySUs' is set to 1, not useful for NpM

2. The following log will come:
amfd[16914]: NO 'saAmfSGNumPrefStandbySUs' is set to 1, not useful for NpM

3. The following log will come:
osafamfd[16914]: NO 'saAmfSGNumPrefActiveSUs' is set to 1, not useful for NpM

4. No log will come.

5. No log will come.

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 

[devel] [PATCH 1 of 1] amfd: log about invalid configuration of saAmfSGNumPrefActiveSUs/StandbySUs [#296]

2015-07-02 Thread nagendra . k
 osaf/services/saf/amf/amfd/sg.cc |  26 +-
 1 files changed, 21 insertions(+), 5 deletions(-)


For NpM, saAmfSGNumPrefActiveSUs and saAmfSGNumPrefStandbySUs are mandatory
attributes to configure. Specs states that there should not be any default
values for these attributes. But in existing code, we are marking them to 1.
If we keep check and reject the configuration without saAmfSGNumPrefActiveSUs
and saAmfSGNumPrefStandbySUs, then there may be backward compatibility issue.
So, in the fix, we just added logs stating that these configurations are
missing. If they are missing, we are setting the values to 1.
But for NpM, setting them to 1 means configuration is almost equivalent to 2N.
So, the fix also throws notice that, setting them to 1 is of not much use.

diff --git a/osaf/services/saf/amf/amfd/sg.cc b/osaf/services/saf/amf/amfd/sg.cc
--- a/osaf/services/saf/amf/amfd/sg.cc
+++ b/osaf/services/saf/amf/amfd/sg.cc
@@ -318,12 +318,28 @@ static AVD_SG *sg_create(const SaNameT *
sg-saAmfSGAutoAdjust = sgt-saAmfSgtDefAutoAdjust;
}
 
-   if 
(immutil_getAttr(const_castSaImmAttrNameT(saAmfSGNumPrefActiveSUs), 
attributes, 0, sg-saAmfSGNumPrefActiveSUs) != SA_AIS_OK) {
-   sg-saAmfSGNumPrefActiveSUs = 1;
-   }
+   if (sgt-saAmfSgtRedundancyModel == SA_AMF_NPM_REDUNDANCY_MODEL) {
+   /* saAmfSGNumPrefActiveSUs and saAmfSGNumPrefStandbySUs are set 
to 1 by default in imm.xml.
+  So, immutil_getAttr will always return OK even if user 
doesn't configure them.
+  Later on if these attr are removed from imm.xml, then the 
below check can be used. */
+   if 
(immutil_getAttr(const_castSaImmAttrNameT(saAmfSGNumPrefActiveSUs),
+   attributes, 0, 
sg-saAmfSGNumPrefActiveSUs) != SA_AIS_OK) {
+   LOG_WA(Mandatory attr 'saAmfSGNumPrefActiveSUs' not 
configured for NpM);
+   sg-saAmfSGNumPrefActiveSUs = 1;
+   }
+   if ((sg-saAmfSGNumPrefActiveSUs == 0) || 
(sg-saAmfSGNumPrefActiveSUs == 1))
+   LOG_NO('saAmfSGNumPrefActiveSUs' is set to %u, not 
useful for NpM,
+   sg-saAmfSGNumPrefActiveSUs);
 
-   if 
(immutil_getAttr(const_castSaImmAttrNameT(saAmfSGNumPrefStandbySUs), 
attributes, 0, sg-saAmfSGNumPrefStandbySUs) != SA_AIS_OK) {
-   sg-saAmfSGNumPrefStandbySUs = 1;
+   if 
(immutil_getAttr(const_castSaImmAttrNameT(saAmfSGNumPrefStandbySUs),
+   attributes, 0, 
sg-saAmfSGNumPrefStandbySUs) != SA_AIS_OK) {
+   LOG_WA(Mandatory attr 'saAmfSGNumPrefStandbySUs' not 
configured for NpM);
+   sg-saAmfSGNumPrefStandbySUs = 1;
+   }
+
+   if ((sg-saAmfSGNumPrefStandbySUs == 0) || 
(sg-saAmfSGNumPrefStandbySUs == 1))
+   LOG_NO('saAmfSGNumPrefStandbySUs' is set to %u, not 
useful for NpM,
+   sg-saAmfSGNumPrefStandbySUs);
}
 
if 
(immutil_getAttr(const_castSaImmAttrNameT(saAmfSGNumPrefInserviceSUs), 
attributes, 0, sg-saAmfSGNumPrefInserviceSUs) != SA_AIS_OK) {

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: validate su existance in sirankedsu object create [#164]

2015-07-01 Thread nagendra . k
 osaf/services/saf/amf/amfd/sirankedsu.cc |  17 +
 1 files changed, 17 insertions(+), 0 deletions(-)


Amf is allowing to create sirankedsu object even if su
mentioned in that object doesn't exist.
Ideally Amf should throw error for such cases.
For creation of association object, both the associated objects
should exists

diff --git a/osaf/services/saf/amf/amfd/sirankedsu.cc 
b/osaf/services/saf/amf/amfd/sirankedsu.cc
--- a/osaf/services/saf/amf/amfd/sirankedsu.cc
+++ b/osaf/services/saf/amf/amfd/sirankedsu.cc
@@ -244,6 +244,7 @@ static int is_config_valid(const SaNameT
SaNameT si_name;
 uint32_t rank = 0;
AVD_SUS_PER_SI_RANK_INDX indx;
+   AVD_SU *avd_su = NULL;
 
 memset(su_name, 0, sizeof(SaNameT));
 memset(si_name, 0, sizeof(SaNameT));
@@ -266,6 +267,22 @@ static int is_config_valid(const SaNameT
 }
 }
 
+   /* Find the su name. */
+   avd_su = su_db-find(Amf::to_string(su_name));
+   if (avd_su == NULL) {
+   /* SU does not exist in current model, check CCB */
+   if (opdata == NULL) {
+   report_ccb_validation_error(opdata, '%s' does not 
exist in model, su_name.value);
+   return 0;
+   }
+
+   if (ccbutil_getCcbOpDataByDN(opdata-ccbId, su_name) == NULL) {
+   report_ccb_validation_error(opdata, '%s' does not 
exist in existing model or in CCB,
+   su_name.value);
+   return 0;
+   }
+   }
+
if (immutil_getAttr(const_castSaImmAttrNameT(saAmfRank), 
attributes, 0, rank) != SA_AIS_OK) {
report_ccb_validation_error(opdata, saAmfRank not found for 
%s, dn-value);
return 0;  

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
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: make ccb op and mw si swap mutually exclusive [#1105]

2015-06-26 Thread nagendra . k
Summary: amfd: make ccb op and mw si swap mutually exclusive [#1105]
Review request for Trac Ticket(s): #1105
Peer Reviewer(s): Praveen, Hans N, Anders Bj, Neel, Mathi
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset f4669df35f65e734ef095651883c95ea2df46357
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Fri, 26 Jun 2015 14:41:21 +0530

amfd: make ccb op and mw si swap mutually exclusive [#1105] If ccb op is
going on and mw s/w is issued then, some times, Amf stuck in imm apis. 
The
reason is if ccb op is going on, then imm doesn't allow to set 
implementer
and Amf hangs. So, Ccb and mw switch op should not be allowed to run
together. 1. Reject ccb op if mw si swap is going on. 2. Reject mw si 
swap
if ccb op is going on.


Complete diffstat:
--
 osaf/libs/common/immsv/include/immutil.h |   8 
 osaf/services/saf/amf/amfd/imm.cc|  43 
+++
 osaf/services/saf/amf/amfd/sg_2n_fsm.cc  |   9 +
 osaf/tools/safimm/src/immutil.c  |   7 +++
 4 files changed, 63 insertions(+), 4 deletions(-)


Testing Commands:
-
1. Issue ccb op and then issue si swap.
2. Issue si swap and then issue ccb op.
3. Tested couple  of swichover and failover.

Testing, Expected Results:
--
1.
error - saImmOmAdminOperationInvoke_2 admin-op RETURNED: SA_AIS_ERR_TRY_AGAIN 
(6)
error-string: SI Swap of safSi=SC-2N,safApp=OpenSAF failed

Syslog: 
Jun 26 14:45:32 PM_SC-1 osafamfd[10359]: NO safSi=SC-2N,safApp=OpenSAF SWAP 
failed - Ccb going on


2. 
For create:
error - saImmOmCcbObjectCreate_2 FAILED with SA_AIS_ERR_FAILED_OPERATION (21)
OI reports: Ccb create failed, m/w role switch going on

For modify:
error - saImmOmCcbObjectModify_2 FAILED: SA_AIS_ERR_FAILED_OPERATION (21)
OI reports: Ccb modify failed, m/w role switch going on

For delete:
error - saImmOmCcbApply FAILED: SA_AIS_ERR_FAILED_OPERATION (21)
OI reports: Ccb delete failed, m/w role switch going on

3. Works fine.

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 

[devel] [PATCH 0 of 1] Review Request for amfnd: mark su in instantiating state [#1392]

2015-06-23 Thread nagendra . k
Summary: amfnd: mark su in instantiating state [#1392]
Review request for Trac Ticket(s): #1392
Peer Reviewer(s): Praveen, Hans N
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset 8be81699780b7473f50e9e23038d6292dd81753a
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Tue, 23 Jun 2015 16:39:01 +0530

amfnd: mark su in instantiating state [#1392] When Su is in instantiated
state(with one component configured with component-failover) and is in
unassigned state and if component crashes, then Amf is not marking SU in
instantiating state when Amf is instantiating the component in that SU. 
This
leads to SU remain in uninstantiated state. So, Amf now marks Su in
instantiating state if the component in that SU is getting instantiated.


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


Testing Commands:
-
As per ticket.

Testing, Expected Results:
--
Su and Component will be in instantiated state with oper
state enabled.

Conditions of Submission:
-
Ack from peer 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 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.


--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] tools/amf: fix errors during switchover/failover [#1384]

2015-06-17 Thread nagendra . k
 osaf/tools/scripts/amf-state |  7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)


Imm returns Empty as value for the non-persistent runtime attributes when 
there is
no implementer for the correcponding amf objects. This can happen during
controller switchover or failover when amf-state script is executed.

This throws errors during amf-state script execution because there
is no check for 'Empty' string before comparing it with intergers.

diff --git a/osaf/tools/scripts/amf-state b/osaf/tools/scripts/amf-state
--- a/osaf/tools/scripts/amf-state
+++ b/osaf/tools/scripts/amf-state
@@ -34,7 +34,7 @@ amf_state()
adm_state_val=`immlist -a saAmfSIAdminState $si_dn | cut -d = 
-f2`
ass_state_val=`immlist -a saAmfSIAssignmentState $si_dn | cut 
-d = -f2`
 
-   if [ $adm_state_val -eq 1 ]  [ $ass_state_val -eq 1 ]; then
+   if [ $adm_state_val -eq 1 ]  [ $ass_state_val != Empty ] 
 [ $ass_state_val -eq 1 ]; then
echo$si_dn
fi
 
@@ -47,7 +47,7 @@ amf_state()
adm_state_val=`immlist -a saAmfSUAdminState $su_dn | cut -d = 
-f2`
oper_state_val=`immlist -a saAmfSUOperState $su_dn | cut -d = 
-f2`
 
-   if [ $adm_state_val -eq 1 ]  [ $oper_state_val -eq 2 ]; then
+   if [ $adm_state_val -eq 1 ]  [ $oper_state_val != Empty ] 
  [ $oper_state_val -eq 2 ]; then
echo$su_dn
fi
done
@@ -58,8 +58,7 @@ amf_state()
for node_dn in $node_dns; do
adm_state_val=`immlist -a saAmfNodeAdminState $node_dn | cut 
-d = -f2`
oper_state_val=`immlist -a saAmfNodeOperState $node_dn | cut 
-d = -f2`
-
-   if [ $adm_state_val -eq 1 ]  [ $oper_state_val -eq 2 ]; then
+   if [ $adm_state_val -eq 1 ]  [ $oper_state_val != Empty ] 
  [ $oper_state_val -eq 2 ]; then
echo$node_dn
fi
done

--
___
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 tools/amf: fix errors during switchover/failover [#1384]

2015-06-17 Thread nagendra . k
Summary: tools/amf: fix errors during switchover/failover [#1384]
Review request for Trac Ticket(s): #1384
Peer Reviewer(s): Praveen, Hans N, Thuan
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset 7ef2abe963ade4b44059e5babecf1d261894317c
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Wed, 17 Jun 2015 11:46:49 +0530

tools/amf: fix errors during switchover/failover [#1384] Imm returns 
Empty
as value for the non-persistent runtime attributes when there is no
implementer for the correcponding amf objects. This can happen during
controller switchover or failover when amf-state script is executed.

This throws errors during amf-state script execution because there is no
check for 'Empty' string before comparing it with intergers.


Complete diffstat:
--
 osaf/tools/scripts/amf-state |  7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)


Testing Commands:
-
Perform 'sh osaf/tools/scripts/amf-state' during switchover.

Testing, Expected Results:
--
Output:
Service Instances UNLOCKED and UNASSIGNED:
Service Units UNLOCKED and DISABLED:
Nodes UNLOCKED and DISABLED:

Conditions of Submission:
-
Ack from peer 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 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.


--
___
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: wait for applcation exit during its termimation [#1375]

2015-06-09 Thread nagendra . k
Summary: amfnd: wait for applcation exit during its termimation [#1375]
Review request for Trac Ticket(s): #1375
Peer Reviewer(s): Praveen, Hans N, Mathi, Anders W 
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset e79a993667ee0ba741d3205d29e09e2439e842be
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Tue, 09 Jun 2015 19:07:52 +0530

amfnd: wait for applcation exit during its termimation [#1375] During 
appl
termination, amf issues instantiate cmd immediately after it receives 
appl
termination resp. There is possibility that application may not have 
exited
before Amf issues instantiate cmd and instantiate command may hang. So, 
Amf
need to wait till appl exit after Amf receives termination response. If 
appl
doesnot exit within termination cbk timeout, then Amf sends cleanup 
command.
If there is some fault(like error report) happened after appl sends term
resp and before application exits, Amf will take actions accordingly.


Complete diffstat:
--
 osaf/services/saf/amf/amfnd/cbq.cc  |  31 
+++
 osaf/services/saf/amf/amfnd/comp.cc |  14 +-
 osaf/services/saf/amf/amfnd/err.cc  |  12 
 osaf/services/saf/amf/amfnd/include/avnd_comp.h |   1 +
 4 files changed, 53 insertions(+), 5 deletions(-)


Testing Commands:
-
1. Configure Sa-Aware PI component.
1.1 Lock-in: Respond Amf for term callback and exit after delay.
 Appl gets successfully uninstantiated.
1.2. Lock-in: Donot send term cbk response and allow timeout to happen.
  Appl gets cleanup and becomes uninstantiated.
1.3. Component restart: Respond Amf for term callback and exit after delay.
 Appl gets successfully instantiated.
1.4. Component restart: Donot send term cbk response and allow timeout to 
happen.
 Appl gets successfully instantiated.

2. Configure proxied PI component and repeat the above cases.

Testing, Expected Results:
--
1.1 Appl/su gets successfully uninstantiated.
1.2 Appl/su gets cleanup and becomes uninstantiated.
1.3 Appl gets successfully instantiated.
1.4 Appl gets successfully instantiated.

The same happens for proxied PI component. 

Conditions of Submission:
-
Ack from peer 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

[devel] [PATCH 1 of 1] amfnd: wait for applcation exit during its termimation [#1375]

2015-06-09 Thread nagendra . k
 osaf/services/saf/amf/amfnd/cbq.cc  |  31 +---
 osaf/services/saf/amf/amfnd/comp.cc |  14 ++-
 osaf/services/saf/amf/amfnd/err.cc  |  12 +
 osaf/services/saf/amf/amfnd/include/avnd_comp.h |   1 +
 4 files changed, 53 insertions(+), 5 deletions(-)


During appl termination, amf issues instantiate cmd immediately after
it receives appl termination resp. There is possibility that application
may not have exited before Amf issues instantiate cmd and instantiate command
may hang.
So, Amf need to wait till appl exit after Amf receives termination response.
If appl doesnot exit within termination cbk timeout, then Amf
sends cleanup command.
If there is some fault(like error report) happened after appl sends
term resp and before application exits, Amf will take actions
accordingly.

diff --git a/osaf/services/saf/amf/amfnd/cbq.cc 
b/osaf/services/saf/amf/amfnd/cbq.cc
--- a/osaf/services/saf/amf/amfnd/cbq.cc
+++ b/osaf/services/saf/amf/amfnd/cbq.cc
@@ -376,10 +376,22 @@ uint32_t avnd_evt_ava_resp_evh(AVND_CB *
m_AVND_COMP_TERM_FAIL_SET(comp);
m_AVND_SEND_CKPT_UPDT_ASYNC_UPDT(cb, comp, 
AVND_CKPT_COMP_FLAG_CHANGE);
}
-
-   rc = avnd_comp_clc_fsm_run(cb, comp, (SA_AIS_OK == resp-err) ?
-  AVND_COMP_CLC_PRES_FSM_EV_TERM_SUCC 
: AVND_COMP_CLC_PRES_FSM_EV_CLEANUP);
-   avnd_comp_cbq_rec_pop_and_del(cb, comp, cbk_rec, false);
+   /* For successful response from (1.) Sa-Aware PI component, wait
+  for down event to come, don't run clc here, run clc when down
+  event comes. (2.) proxied PI, no down event
+  expected, so run clc here. In case of failure response from
+  any body, follow the clc. No need to check for PI along with
+  proxied, because in case of PI only, term response will come
+  back from component. */
+   if((SA_AIS_OK == resp-err)  
(!m_AVND_COMP_TYPE_IS_PROXIED(comp)))  {
+   /* Save invocation value to delete cbq record when
+  down event comes. */
+   comp-term_cbq_inv_value = resp-inv;
+   } else {
+   rc = avnd_comp_clc_fsm_run(cb, comp, (SA_AIS_OK == 
resp-err) ?
+   AVND_COMP_CLC_PRES_FSM_EV_TERM_SUCC : 
AVND_COMP_CLC_PRES_FSM_EV_CLEANUP);
+   avnd_comp_cbq_rec_pop_and_del(cb, comp, cbk_rec, false);
+   }
 
// if all OK send a response to the client
if ((rc == NCSCC_RC_SUCCESS)  (resp-err == SA_AIS_OK)) {
@@ -563,6 +575,17 @@ uint32_t avnd_evt_tmr_cbk_resp_evh(AVND_
} else if (AVSV_AMF_COMP_TERM == rec-cbk_info-type) {
m_AVND_COMP_TERM_FAIL_SET(rec-comp);
m_AVND_SEND_CKPT_UPDT_ASYNC_UPDT(cb, rec-comp, 
AVND_CKPT_COMP_FLAG_CHANGE);
+   if (rec-comp-term_cbq_inv_value != 0) {
+   AVND_COMP_CBK *cbk_rec;
+   /* Since, the cbq timer has expired and no down event
+  came, get the matching entry from the cbk list and
+  delete the cbq. */
+   m_AVND_COMP_CBQ_INV_GET(rec-comp, 
rec-comp-term_cbq_inv_value, cbk_rec);
+   rec-comp-term_cbq_inv_value = 0;
+   if (cbk_rec) {
+   avnd_comp_cbq_rec_pop_and_del(cb, rec-comp, 
cbk_rec, false);
+   }
+   }
rc = avnd_comp_clc_fsm_run(cb, rec-comp, 
AVND_COMP_CLC_PRES_FSM_EV_CLEANUP);
} else {
switch (rec-cbk_info-type) {
diff --git a/osaf/services/saf/amf/amfnd/comp.cc 
b/osaf/services/saf/amf/amfnd/comp.cc
--- a/osaf/services/saf/amf/amfnd/comp.cc
+++ b/osaf/services/saf/amf/amfnd/comp.cc
@@ -381,12 +381,24 @@ uint32_t avnd_evt_mds_ava_dn_evh(AVND_CB
}   /* for */
 
if (comp) {
+   if (comp-term_cbq_inv_value != 0) {
+   AVND_COMP_CBK *cbk_rec;
+   /* Amf was waiting for this down event. Get the matching
+  entry from the cbk list and delete the cbq */
+   m_AVND_COMP_CBQ_INV_GET(comp, comp-term_cbq_inv_value, 
cbk_rec);
+   comp-term_cbq_inv_value = 0;
+   rc = avnd_comp_clc_fsm_run(cb, comp, 
AVND_COMP_CLC_PRES_FSM_EV_TERM_SUCC);
+   if (cbk_rec)
+   avnd_comp_cbq_rec_pop_and_del(cb, comp, 
cbk_rec, false);
+   goto done;
+   }
/* found the matching comp; trigger error processing */
err_info.src = AVND_ERR_SRC_AVA_DN;
err_info.rec_rcvr.avsv_ext = 

[devel] [PATCH 1 of 1] amfd: ignore invalid modification of saAmfSGMaxActiveSIsperSU/saAmfSGMaxStandbySIsperSU [#1361]

2015-05-21 Thread nagendra . k
 osaf/services/saf/amf/amfd/sg.cc |  31 +--
 1 files changed, 25 insertions(+), 6 deletions(-)


saAmfSGMaxActiveSIsperSU is valid for NPM, N_WAY and N_WAY_ACTIVE and
invalid for Nored and 2N. So, modification of this attribute for
 Nored and 2N redudancy models should be ignored.

saAmfSGMaxStandbySIsperSU is valid for NPM and N_WAY and
invalid for Nored, 2N and NwayAct. So, modification of this attribute for
Nored, 2N and NwayAct redudancy models should be ignored.

diff --git a/osaf/services/saf/amf/amfd/sg.cc b/osaf/services/saf/amf/amfd/sg.cc
--- a/osaf/services/saf/amf/amfd/sg.cc
+++ b/osaf/services/saf/amf/amfd/sg.cc
@@ -919,15 +919,34 @@ static void ccb_apply_modify_hdlr(CcbUti
} else if (!strcmp(attribute-attrName, 
saAmfSGMaxActiveSIsperSU)) {
if (value_is_deleted)
sg-saAmfSGMaxActiveSIsperSU = -1;
-   else
-   sg-saAmfSGMaxActiveSIsperSU = 
*((SaUint32T *)value);
-   TRACE(Modified saAmfSGMaxActiveSIsperSU is 
'%u', sg-saAmfSGMaxActiveSIsperSU);
+   else {
+   if ((sg-sg_redundancy_model == 
SA_AMF_NPM_REDUNDANCY_MODEL) ||
+   
(sg-sg_redundancy_model == SA_AMF_N_WAY_REDUNDANCY_MODEL) ||
+   
(sg-sg_redundancy_model == SA_AMF_N_WAY_ACTIVE_REDUNDANCY_MODEL)) {
+   sg-saAmfSGMaxActiveSIsperSU = 
*((SaUint32T *)value);
+   TRACE(Modified 
saAmfSGMaxActiveSIsperSU is '%u',
+   
sg-saAmfSGMaxActiveSIsperSU);
+   } else {
+   LOG_NO('%s' attribute 
saAmfSGMaxActiveSIsperSU not modified,
+not valid for 
Nored/2N Redundancy models,
+   sg-name.value);
+   }
+   }
} else if (!strcmp(attribute-attrName, 
saAmfSGMaxStandbySIsperSU)) {
if (value_is_deleted)
sg-saAmfSGMaxStandbySIsperSU = -1;
-   else
-   sg-saAmfSGMaxStandbySIsperSU = 
*((SaUint32T *)value);
-   TRACE(Modified saAmfSGMaxStandbySIsperSU is 
'%u', sg-saAmfSGMaxStandbySIsperSU);
+   else {
+   if ((sg-sg_redundancy_model == 
SA_AMF_NPM_REDUNDANCY_MODEL) ||
+   
(sg-sg_redundancy_model == SA_AMF_N_WAY_REDUNDANCY_MODEL)) {
+   sg-saAmfSGMaxStandbySIsperSU = 
*((SaUint32T *)value);
+   TRACE(Modified 
saAmfSGMaxStandbySIsperSU is '%u',
+   
sg-saAmfSGMaxStandbySIsperSU);
+   } else {
+   LOG_NO('%s' attribute 
saAmfSGMaxStandbySIsperSU not modified,
+not valid for 
Nored/2N/NwayAct Redundancy models,
+   sg-name.value);
+   }
+   }
} else if (!strcmp(attribute-attrName, 
saAmfSGAutoAdjustProb)) {
if (value_is_deleted)
sg-saAmfSGAutoAdjustProb = 
sg_type-saAmfSgtDefAutoAdjustProb;

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: try again if ImplementerClear times out

2015-05-12 Thread nagendra . k
 osaf/services/saf/amf/amfd/role.cc |  9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)


ImplementerClear returns SA_AIS_ERR_TIMEOUT because the message
sent from immnd to immd got lost because of node down.
So, Amf need to handle it as try_again.
After Amf does try_again, Imm returns SA_AIS_ERR_BAD_HANDLE.
Amf handles SA_AIS_ERR_BAD_HANDLE and reinitializes its interface with Imm.
In handling SA_AIS_ERR_BAD_HANDLE, Amf sets the implementer in 
avd_imm_reinit_bg_thread, so
when Amf proceeds and calls avd_imm_applier_set, Imm returns
SA_AIS_ERR_INVALID_PARAM. Since, it is expected error from Imm,
Amf ignores it.

diff --git a/osaf/services/saf/amf/amfd/role.cc 
b/osaf/services/saf/amf/amfd/role.cc
--- a/osaf/services/saf/amf/amfd/role.cc
+++ b/osaf/services/saf/amf/amfd/role.cc
@@ -659,15 +659,17 @@ void avd_mds_qsd_role_evh(AVD_CL_CB *cb,
_exit(EXIT_FAILURE); // should never get here...
}
 
+try_again:
/* Take mutex here to sync with imm reinit thread.*/
osaf_mutex_lock_ordie(imm_reinit_mutex);
-
/* Give up IMM OI implementer role */
if ((rc = immutil_saImmOiImplementerClear(cb-immOiHandle)) != 
SA_AIS_OK) {
osaf_mutex_unlock_ordie(imm_reinit_mutex);
LOG_ER(FAILOVER Active -- Quiesced FAILED, ImplementerClear 
failed %u, rc);
if (rc == SA_AIS_ERR_BAD_HANDLE) {
avd_imm_reinit_bg();
+   } else if (rc == SA_AIS_ERR_TIMEOUT) {
+   goto try_again;
} else
osafassert(0);
} else
@@ -685,10 +687,11 @@ void avd_mds_qsd_role_evh(AVD_CL_CB *cb,
LOG_ER(avd_imm_applier_set FAILED, %u, rc);
if (rc == SA_AIS_ERR_BAD_HANDLE) {
avd_imm_reinit_bg();
-   } else if (rc == SA_AIS_ERR_EXIST) {
+   } else if ((rc == SA_AIS_ERR_EXIST) || (rc == 
SA_AIS_ERR_INVALID_PARAM)) {
/* This may arise if immutil_saImmOiImplementerClear
   failed and amf reinitializes imm interface and
-  set applier in avd_imm_reinit_bg_thread.*/
+  set applier in avd_imm_reinit_bg_thread. Imm may
+  return ERR_EXIST or INVALID_PARAM. */
} else
osafassert(0);
} else

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: avoid null pointer access [#1365]

2015-05-05 Thread nagendra . k
 osaf/services/saf/amf/amfd/role.cc |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


During node failover if node is not found at amfd,
then my_node remains null and amfd access it in the end.
It needs to avoided as amfd crashes.

diff --git a/osaf/services/saf/amf/amfd/role.cc 
b/osaf/services/saf/amf/amfd/role.cc
--- a/osaf/services/saf/amf/amfd/role.cc
+++ b/osaf/services/saf/amf/amfd/role.cc
@@ -366,7 +366,8 @@ static uint32_t avd_role_failover(AVD_CL
 
 done:
if (NCSCC_RC_SUCCESS != status)
-   opensaf_reboot(my_node-node_info.nodeId, (char 
*)my_node-node_info.executionEnvironment.value,
+   opensaf_reboot(my_node != NULL ? my_node-node_info.nodeId : 0,
+   my_node != NULL ? (char 
*)my_node-node_info.executionEnvironment.value : NULL,
FAILOVER failed);
 
 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
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: ignore si rank modification for the same value [#1336]

2015-04-30 Thread nagendra . k
Summary: amfd: ignore si rank modification for the same value [#1336]
Review request for Trac Ticket(s): #1336
Peer Reviewer(s): Praveen, Hans N
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset bf18c6c03472a2eb976a6e1cd7c37cf7a30a5bb4
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Thu, 30 Apr 2015 15:41:05 +0530

amfd: ignore si rank modification for the same value [#1336] Amfd 
rejects
ccb modification operation on si rank if its current si rank value is 
being
modified by the same value. Amfd can accept it and ignore the changes to
avoid ccb abort.


Complete diffstat:
--
 osaf/services/saf/amf/amfd/si.cc |  13 +
 1 files changed, 5 insertions(+), 8 deletions(-)


Testing Commands:
-
Start Amf demo with si rank configured as 1 and run
immcfg -m -a saAmfSIRank=1 safSi=AmfDemo,safApp=AmfDemo1


Testing, Expected Results:
--
Amf accepts the command and honour ccb.

Conditions of Submission:
-
Ack from peer 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 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.


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: ignore si rank modification for the same value [#1336]

2015-04-30 Thread nagendra . k
 osaf/services/saf/amf/amfd/si.cc |  13 +
 1 files changed, 5 insertions(+), 8 deletions(-)


Amfd rejects ccb modification operation on si rank if
its current si rank value is being modified by
the same value.
Amfd can accept it and ignore the changes to avoid ccb  abort.

diff --git a/osaf/services/saf/amf/amfd/si.cc b/osaf/services/saf/amf/amfd/si.cc
--- a/osaf/services/saf/amf/amfd/si.cc
+++ b/osaf/services/saf/amf/amfd/si.cc
@@ -778,12 +778,6 @@ static SaAisErrorT si_ccb_completed_modi

SaUint32T sirank = 
*(SaUint32T*)attribute-attrValues[0];
 
-   if (si-saAmfSIRank == (sirank == 0 ? ~0U : sirank)) {
-   report_ccb_validation_error(opdata, Changing 
same value of saAmfSIRank(%u), sirank);
-   rc = SA_AIS_ERR_EXIST;
-   break;
-   }
-
if (!si-is_sirank_valid(sirank)) {
report_ccb_validation_error(opdata, 
saAmfSIRank(%u) is invalid due to SI Dependency rules, sirank);
rc = SA_AIS_ERR_BAD_OPERATION;
@@ -1205,8 +1199,11 @@ static void si_ccb_apply_modify_hdlr(Ccb
} else if (!strcmp(attribute-attrName, saAmfSIRank)) {
if (value_is_deleted == true)
si-update_sirank(0);
-   else
-   si-update_sirank(*((SaUint32T 
*)attr_mod-modAttr.attrValues[0]));
+   else {
+   /* Ignore the modification with the same value. 
*/
+   if (si-saAmfSIRank != *((SaUint32T 
*)attr_mod-modAttr.attrValues[0]))
+   si-update_sirank(*((SaUint32T 
*)attr_mod-modAttr.attrValues[0]));
+   }
TRACE(Modified saAmfSIRank is '%u', si-saAmfSIRank);
} else {
osafassert(0);

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: send data verify message to node in NO_CONFIG and NCS_INIT also [#1359]

2015-04-30 Thread nagendra . k
 osaf/services/saf/amf/amfd/ndfsm.cc |  4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)


When Amfd is comming up as Act, it is not sending data verify message to node,
which is in state AVD_AVND_STATE_NO_CONFIG and AVD_AVND_STATE_NCS_INIT.
This creates problem of marking the upcoming node in AVD_AVND_STATE_GO_DOWN and
this stops that node to join the cluster.
When node has just come up and sent node up message to Act amfd and at that time
if Act Amfd node goes for switchover or failover, then that node has to
contact to newly Act Amfd for further communication.
So, that node needs to get data verify message from newly Amfd.

diff --git a/osaf/services/saf/amf/amfd/ndfsm.cc 
b/osaf/services/saf/amf/amfd/ndfsm.cc
--- a/osaf/services/saf/amf/amfd/ndfsm.cc
+++ b/osaf/services/saf/amf/amfd/ndfsm.cc
@@ -405,7 +405,9 @@ void avd_fail_over_event(AVD_CL_CB *cb)
 * Check if we are in present state. If yes then send DATA 
verify 
 * message to all the AVND's.
 */
-   if (AVD_AVND_STATE_PRESENT == avnd-node_state) {
+   if ((AVD_AVND_STATE_PRESENT == avnd-node_state) ||
+   (AVD_AVND_STATE_NO_CONFIG == avnd-node_state) 
||
+   (AVD_AVND_STATE_NCS_INIT == avnd-node_state)) {
/*
 * Send verify message to this node.
 */

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
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: send data verify message to node in NO_CONFIG and NCS_INIT also [#1359]

2015-04-30 Thread nagendra . k
Summary: amfd: send data verify message to node in NO_CONFIG and NCS_INIT also 
[#1359]
Review request for Trac Ticket(s): #1359
Peer Reviewer(s): Praveen, Hans N 
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset 04e7947a39da3f03db780f8c0a4bb3d60e838755
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Thu, 30 Apr 2015 17:36:38 +0530

amfd: send data verify message to node in NO_CONFIG and NCS_INIT also
[#1359] When Amfd is comming up as Act, it is not sending data verify
message to node, which is in state AVD_AVND_STATE_NO_CONFIG and
AVD_AVND_STATE_NCS_INIT. This creates problem of marking the upcoming 
node
in AVD_AVND_STATE_GO_DOWN and this stops that node to join the cluster. 
When
node has just come up and sent node up message to Act amfd and at that 
time
if Act Amfd node goes for switchover or failover, then that node has to
contact to newly Act Amfd for further communication. So, that node 
needs to
get data verify message from newly Amfd.


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


Testing Commands:
-
Start SC-1 and SC-2.
Keep sleep of 5 sec in immnd instantiate script on PL-3 and start PL-3.
When PL-3 is waiting for immnd to get instantiated, do a controller switchover
or controller failover.

Testing, Expected Results:
--
PL-3 should come up.

Conditions of Submission:
-
Ack from peer 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 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.


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications

[devel] [PATCH 1 of 1] amfd: respond to nid only after initialization is completed [#1334]

2015-04-27 Thread nagendra . k
 osaf/services/saf/amf/amfd/chkop.cc |  4 
 osaf/services/saf/amf/amfd/main.cc  |  6 +-
 2 files changed, 9 insertions(+), 1 deletions(-)


Act Amfd initialization is said to be completed when
it completes its initialization with imm.
Apart from initializing with imm, Standby Amfd
also need to get run time data from Act Amfd using cold sync.
So, Standby Amfd initialization is said to be completed when
it completes its initialization with imm and it completes its
cold sync with Act Amfd.
In the present code, Standby is sending response to nid without
cold sync complete.
So, code has been added to send nid response only when Amfd
completes its initialization.

diff --git a/osaf/services/saf/amf/amfd/chkop.cc 
b/osaf/services/saf/amf/amfd/chkop.cc
--- a/osaf/services/saf/amf/amfd/chkop.cc
+++ b/osaf/services/saf/amf/amfd/chkop.cc
@@ -40,6 +40,7 @@
 
 #include logtrace.h
 #include amfd.h
+#include nid_api.h
 
 static uint32_t avsv_mbcsv_cb(NCS_MBCSV_CB_ARG *arg);
 static uint32_t avsv_mbcsv_process_enc_cb(AVD_CL_CB *cb, NCS_MBCSV_CB_ARG 
*arg);
@@ -444,6 +445,9 @@ ignore_msg:
** when in a more critical state */
saflog(LOG_NOTICE, amfSvcUsrName, Cold sync 
complete at %x, cb-node_id_avd);
cb-stby_sync_state = AVD_STBY_IN_SYNC;
+   /* It is important for Standby Amfd to inform 
nid after it is
+  ready for Act controller failover and accept 
Act role. */
+   (void) nid_notify(const_castchar*(AMFD), 
NCSCC_RC_SUCCESS, NULL);
}
 
cb-synced_reo_type = arg-info.decode.i_reo_type;
diff --git a/osaf/services/saf/amf/amfd/main.cc 
b/osaf/services/saf/amf/amfd/main.cc
--- a/osaf/services/saf/amf/amfd/main.cc
+++ b/osaf/services/saf/amf/amfd/main.cc
@@ -831,7 +831,11 @@ int main(int argc, char *argv[])
exit(EXIT_FAILURE);
}
 
-   (void) nid_notify(const_castchar*(AMFD), NCSCC_RC_SUCCESS, NULL);
+   /* Act Amfd need to inform nid after it has initialized itself, while
+  Stanby Amfd need to inform nid after it has done cold sync. */
+   if (avd_cb-avail_state_avd == SA_AMF_HA_ACTIVE) {
+   (void) nid_notify(const_castchar*(AMFD), NCSCC_RC_SUCCESS, 
NULL);
+   }
 
main_loop();
 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
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: respond to nid only after initialization is completed [#1334]

2015-04-27 Thread nagendra . k
Summary: amfd: respond to nid only after initialization is completed [#1334]
Review request for Trac Ticket(s): #1334
Peer Reviewer(s): Mathi, Hans N, Praveen
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset eeba7fe22afb8f4c40bb393d45a108cc59061eda
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Mon, 27 Apr 2015 14:41:02 +0530

amfd: respond to nid only after initialization is completed [#1334] Act 
Amfd
initialization is said to be completed when it completes its 
initialization
with imm. Apart from initializing with imm, Standby Amfd also need to 
get
run time data from Act Amfd using cold sync. So, Standby Amfd 
initialization
is said to be completed when it completes its initialization with imm 
and it
completes its cold sync with Act Amfd. In the present code, Standby is
sending response to nid without cold sync complete. So, code has been 
added
to send nid response only when Amfd completes its initialization.


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


Testing Commands:
-
1. Start Act controller SC-1.
   Start Standby controller SC-2 and stop SC-1 when
   Standby Amfd is in the middle of cold sync.
2. Start Act controller SC-1.
   Start Standby controller SC-2 and stop SC-1 when
   Standby Amfd has completed cold sync but Amfnd has not asigned
   role to Fmd at Standby controller.


Testing, Expected Results:
--
1. Fmd reboots the node :
Apr 27 12:56:32 PM_SC-2 osaffmd[11792]: Rebooting OpenSAF NodeId = 0 EE Name = 
No EE Mapped, Reason: Failover occurred, but this node is not yet ready, 
OwnNodeId = 131599, SupervisionTime = 60
2. Same as above.

Conditions of Submission:
-
Ack from peer 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 time; confusing the
the threaded patch review.

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

___ 

[devel] [PATCH 1 of 1] amfd: validate node for being nodegroup member [#1311]

2015-04-22 Thread nagendra . k
 osaf/services/saf/amf/amfd/node.cc |  14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)


Amfd is allowing node to be deleted even if node is being part of node group.
This creates database differences because that node is still part of node group,
but it doesn's exists.
When a nodegroup is created and node is added to it, Amfd checks whether
node exists or not. If it doesn't exist, then node addition fails.
This is done in the expectation that node should exists if it want to
be part of node group. This concept should go inline with deletion of node
as well and node deletion shouldn't be allowed until it is part of a nodegroup.

A valiadation has been added when node is being deleted for its membership
of a node group. If node is a part of membership, it can't be deleted. So,
to delete a node, first delete that node from node group.

diff --git a/osaf/services/saf/amf/amfd/node.cc 
b/osaf/services/saf/amf/amfd/node.cc
--- a/osaf/services/saf/amf/amfd/node.cc
+++ b/osaf/services/saf/amf/amfd/node.cc
@@ -453,6 +453,20 @@ static SaAisErrorT node_ccb_completed_de
goto done;
}
}
+
+   /* This node shouldn't be part of any nodegroup. First this node has to 
be deleted from
+  node group. */
+   for (std::mapstd::string, AVD_AMF_NG*::const_iterator it = 
nodegroup_db-begin();
+   it != nodegroup_db-end(); it++) {
+   AVD_AMF_NG *ng = it-second;
+   if (node_in_nodegroup(Amf::to_string((opdata-objectName)), 
ng) == true) {
+   report_ccb_validation_error(opdata, '%s' exists in
+the nodegroup '%s',
+   opdata-objectName.value, 
ng-name.value);
+   rc = SA_AIS_ERR_BAD_OPERATION;
+   goto done;
+   }
+   }
opdata-userData = node;
 done:
TRACE_LEAVE();

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
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: validate node for being nodegroup member [#1311]

2015-04-22 Thread nagendra . k
Summary: amfd: validate node for being nodegroup member [#1311]
Review request for Trac Ticket(s): #1311
Peer Reviewer(s): Hans N, Praveen
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset 4d76c4442805e83eaa7954e31cee26a604d63c13
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Wed, 22 Apr 2015 16:39:04 +0530

amfd: validate node for being nodegroup member [#1311] Amfd is allowing 
node
to be deleted even if node is being part of node group. This creates
database differences because that node is still part of node group, but 
it
doesn's exists. When a nodegroup is created and node is added to it, 
Amfd
checks whether node exists or not. If it doesn't exist, then node 
addition
fails. This is done in the expectation that node should exists if it 
want to
be part of node group. This concept should go inline with deletion of 
node
as well and node deletion shouldn't be allowed until it is part of a
nodegroup.

A valiadation has been added when node is being deleted for its 
membership
of a node group. If node is a part of membership, it can't be deleted. 
So,
to delete a node, first delete that node from node group.


Complete diffstat:
--
 osaf/services/saf/amf/amfd/node.cc |  14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)


Testing Commands:
-
1. Start SC-1 with 4 nodes configuration. Lock/lock-in PL-3. Try deleting PL-3 :
   immcfg -d safAmfNode=PL-3,safAmfCluster=myAmfCluster
2. After step 1, Delete PL-3 from node group AllNodes: 
   immcfg -m -a saAmfNGNodeList-=safAmfNode=PL-3,safAmfCluster=myAmfCluster 
safAmfNodeGroup=AllNodes,safAmfCluster=myAmfCluster
3. Delete mw SUs from PL-3:
   immcfg -d safSu=PL-3,safSg=NoRed,safApp=OpenSAF
   Now run the step 2 command.
4. Now try deleting PL-3 : immcfg -d safAmfNode=PL-3,safAmfCluster=myAmfCluster
5. Now delete PL-3 from node group PLs:
   immcfg -m -a saAmfNGNodeList-=safAmfNode=PL-3,safAmfCluster=myAmfCluster 
safAmfNodeGroup=PLs,safAmfCluster=myAmfCluster
   Now delete the node PL-3: immcfg -d 
safAmfNode=PL-3,safAmfCluster=myAmfCluster
6. Now lock and unlock the node group as per ticket description:
   amf-adm lock safAmfNodeGroup=PLs,safAmfCluster=myAmfCluster
   amf-adm unlock safAmfNodeGroup=PLs,safAmfCluster=myAmfCluster
7. Delete the node group: immcfg -d  
safAmfNodeGroup=PLs,safAmfCluster=myAmfCluster

Testing, Expected Results:
--
1. Deletion of PL-3 fails with:
error - saImmOmCcbApply FAILED: SA_AIS_ERR_FAILED_OPERATION (21)
OI reports: 'safAmfNode=PL-3,safAmfCluster=myAmfCluster' exists in the 
nodegroup 'safAmfNodeGroup=AllNodes,safAmfCluster=myAmfCluster'
2. The following error will come:
error - saImmOmCcbApply FAILED: SA_AIS_ERR_FAILED_OPERATION (21)
OI reports: Cannot delete 'safAmfNode=PL-3,safAmfCluster=myAmfCluster' from 
'safAmfNodeGroup=AllNodes,safAmfCluster=myAmfCluster'. An SU is mapped using 
node group
3. Deletion of PL-3 node from safAmfNodeGroup will succeed.
4. Fails with the following error:
error - saImmOmCcbApply FAILED: SA_AIS_ERR_FAILED_OPERATION (21)
OI reports: 'safAmfNode=PL-3,safAmfCluster=myAmfCluster' exists in the 
nodegroup 'safAmfNodeGroup=PLs,safAmfCluster=myAmfCluster'
5. Deletion of PL-3 succeeds.
6. Lock and unlock on the node group 
'safAmfNodeGroup=PLs,safAmfCluster=myAmfCluster' succeeds.
7. Delete of the node group succeeds.

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 

[devel] [PATCH 0 of 1] Review Request for amfa: avoid illigal memory access [#1307]

2015-04-21 Thread nagendra . k
Summary: amfa: avoid illigal memory access [#1307]
Review request for Trac Ticket(s): #1307
Peer Reviewer(s): Hans N, Praveen
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset 58ac51a0311884235906fa4eb3c6b2b9e897c615
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Tue, 21 Apr 2015 16:58:04 +0530

amfa: avoid illigal memory access [#1307] While invalid handle is 
passed to
saAmfProtectionGroupTrack_4, code jumps to done and calls
avsv_nda_ava_msg_content_free(msg). But msg is not meset to zero, so 
it has
garbage values. Inside avsv_nda_ava_msg_content_free, the following code
points to garbage pointer and agent crashes: if (msg-info.cbk_info) {
avsv_amf_cbk_free(msg-info.cbk_info); msg need to be memset before code
jumps to 'done'.


Complete diffstat:
--
 osaf/libs/agents/saf/amfa/ava_api.c |  6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)


Testing Commands:
-
Started controller SC-1.

Testing, Expected Results:
--
SC-1 came up successfully.

Conditions of Submission:
-
Ack from peer 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 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.


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfa: avoid illigal memory access [#1307]

2015-04-21 Thread nagendra . k
 osaf/libs/agents/saf/amfa/ava_api.c |  6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)


While invalid handle is passed to saAmfProtectionGroupTrack_4, code jumps to
done and calls avsv_nda_ava_msg_content_free(msg). But msg is not meset
to zero, so it has garbage values. Inside avsv_nda_ava_msg_content_free, the
following code points to garbage pointer and agent crashes:
if (msg-info.cbk_info) {
avsv_amf_cbk_free(msg-info.cbk_info);
msg need to be memset before code jumps to 'done'.

diff --git a/osaf/libs/agents/saf/amfa/ava_api.c 
b/osaf/libs/agents/saf/amfa/ava_api.c
--- a/osaf/libs/agents/saf/amfa/ava_api.c
+++ b/osaf/libs/agents/saf/amfa/ava_api.c
@@ -2194,6 +2194,9 @@ SaAisErrorT saAmfProtectionGroupTrack_4(
SaAisErrorT rc = SA_AIS_OK;
TRACE_ENTER2(SaAmfHandleT passed is %llx, hdl);
 
+   /* initialize the msg */
+   memset(msg, 0, sizeof(AVSV_NDA_AVA_MSG));
+
/* Verifying the input Handle  global handle */
if(!gl_ava_hdl || hdl  AVSV_UNS32_HDL_MAX) {
TRACE_2(Invalid SaAmfHandle passed by component: %llx,hdl);
@@ -2226,9 +2229,6 @@ SaAisErrorT saAmfProtectionGroupTrack_4(
/* TODO: check cluster membership, if node is not a member answer back 
with SA_AIS_ERR_UNAVAILABLE */
/* TODO: check if handle is old, due to node rejoin as member in 
cluster. If not: SA_AIS_ERR_UNAVAILABLE */
 
-   /* initialize the msg */
-   memset(msg, 0, sizeof(AVSV_NDA_AVA_MSG));
-
if (!csi_name || !(csi_name-length) || (csi_name-length  
SA_MAX_NAME_LENGTH)) {
TRACE_LEAVE2(Incorrect arguments);
rc = SA_AIS_ERR_INVALID_PARAM;

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
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: avoid calling failover function twice [#1298]

2015-04-09 Thread nagendra . k
Summary: amfd: avoid calling failover function twice [#1298]
Review request for Trac Ticket(s): #1298
Peer Reviewer(s): Hans N, Praveen
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset e6c13e57b0575f537cead35abc9e9ba3c18ac1ee
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Thu, 09 Apr 2015 18:13:04 +0530

amfd: avoid calling failover function twice [#1298] When Amfd becomes 
Act,
it is calling node failover function for those nodes also, which were
already gone down and already failover has been performed by older Act 
Amfd.
This needs to be avoided.


Complete diffstat:
--
 osaf/services/saf/amf/amfd/main.cc |  14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)


Testing Commands:
-
Start SC-1, SC-2, PL-3 and PL-4.
1. Stop PL-3 and after it is over, then perform mw switchover.
2. Perform mw switchover and stop PL-3 when received
   'Date Verify' message(avnd_evt_avd_verify_evh). And 
then start PL-3.

Testing, Expected Results:
--
1. 'PL-3 left' will not come.
2. PL-3 left will come and PL-3 will join the cluster.

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


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net

[devel] [PATCH 1 of 1] amfd: avoid calling failover function twice [#1298]

2015-04-09 Thread nagendra . k
 osaf/services/saf/amf/amfd/main.cc |  14 +-
 1 files changed, 13 insertions(+), 1 deletions(-)


When Amfd becomes Act, it is calling node failover
function for those nodes also, which were already gone down
and already failover has been performed by older Act Amfd.
This needs to be avoided.

diff --git a/osaf/services/saf/amf/amfd/main.cc 
b/osaf/services/saf/amf/amfd/main.cc
--- a/osaf/services/saf/amf/amfd/main.cc
+++ b/osaf/services/saf/amf/amfd/main.cc
@@ -405,8 +405,20 @@ static void handle_event_in_failover_sta
for (std::mapuint32_t, AVD_AVND *::const_iterator it = 
node_id_db-begin();
it != node_id_db-end(); it++) {
AVD_AVND *node = it-second;
+   bool fover_done = false;
if (AVD_AVND_STATE_ABSENT == node-node_state) {
-   avd_node_failover(node);
+   /* Check whether this node failover has been
+  performed or not. */
+   for (AVD_SU *i_su = node-list_of_ncs_su; i_su;
+   i_su = i_su-avnd_list_su_next) 
{
+   if 
((i_su-sg_of_su-sg_redundancy_model == SA_AMF_NO_REDUNDANCY_MODEL) 
+   (i_su-list_of_susi == 
NULL)) {
+   fover_done = true;
+   break;
+   }
+   }
+   if (fover_done == false)
+   avd_node_failover(node);
}
}
/* Since we are sending lots of async update to its peer from

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel


[devel] [PATCH 1 of 1] amfd: adjust saAmfSINumCurrStandbyAssignments during HA state change [#1276]

2015-04-07 Thread nagendra . k
 osaf/services/saf/amf/amfd/sgproc.cc |  8 
 1 files changed, 8 insertions(+), 0 deletions(-)


Amfd is not decrementing saAmfSINumCurrStandbyAssignments when
HA state is changing from Quisced to Standby during SU failover.
saAmfSINumCurrStandbyAssignments is increased when Amfd sends
assignment to Amfnd from Quisced to Standby, it need to decrement
saAmfSINumCurrStandbyAssignments if failover happens and assignment was
not successfull.

diff --git a/osaf/services/saf/amf/amfd/sgproc.cc 
b/osaf/services/saf/amf/amfd/sgproc.cc
--- a/osaf/services/saf/amf/amfd/sgproc.cc
+++ b/osaf/services/saf/amf/amfd/sgproc.cc
@@ -464,7 +464,15 @@ static uint32_t sg_su_failover_func(AVD_
   assignment had been sent. So decrement the 
count in SI before 
   deleting the SUSI. */
susi-si-dec_curr_act_ass();
+   } else if ((susi-fsm == AVD_SU_SI_STATE_MODIFY) 
+   (susi-state == SA_AMF_HA_STANDBY)) {
+   /* SUSI is undergoing standby modification. For 
standby state
+  saAmfSINumCurrStandbyAssignments was 
increased when standby
+  assignment had been sent. So decrement the 
count in SI before
+  deleting the SUSI. */
+   susi-si-dec_curr_stdby_ass();
}
+
/* Reply to IMM for admin operation on SI */
if (susi-si-invocation != 0) {

avd_saImmOiAdminOperationResult(avd_cb-immOiHandle,

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
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: adjust saAmfSINumCurrStandbyAssignments during HA state change [#1276]

2015-04-07 Thread nagendra . k
Summary: amfd: adjust saAmfSINumCurrStandbyAssignments during HA state change 
[#1276]
Review request for Trac Ticket(s): #1276
Peer Reviewer(s): Hans N, Praveen
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
Affected branch(es): All
Development branch: Default


Impacted area   Impact y/n

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


Comments (indicate scope for each y above):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset 66cf3e572a702b2e9e05be50d8325fd72390a250
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Tue, 07 Apr 2015 14:29:10 +0530

amfd: adjust saAmfSINumCurrStandbyAssignments during HA state change 
[#1276]
Amfd is not decrementing saAmfSINumCurrStandbyAssignments when HA state 
is
changing from Quisced to Standby during SU failover.
saAmfSINumCurrStandbyAssignments is increased when Amfd sends 
assignment to
Amfnd from Quisced to Standby, it need to decrement
saAmfSINumCurrStandbyAssignments if failover happens and assignment was 
not
successfull.


Complete diffstat:
--
 osaf/services/saf/amf/amfd/sgproc.cc |  8 
 1 files changed, 8 insertions(+), 0 deletions(-)


Testing Commands:
-
As per ticket.

Testing, Expected Results:
--
Did immlist of Si and found saAmfSINumCurrStandbyAssignments
was zero after su failover.

Conditions of Submission:
-
Ack from 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.


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net

[devel] [PATCH 0 of 1] Review Request for amfd: checkpoint node admin state during clm lock [#409]

2015-03-19 Thread nagendra . k
Summary: amfd: checkpoint node admin state during clm lock [#409]
Review request for Trac Ticket(s): #409
Peer Reviewer(s): hans.nordeb...@ericsson.com, praveen.malv...@oracle.com
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset 5da8169d3cfa4457925526dc4c56043f359861f9
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Thu, 19 Mar 2015 14:51:47 +0530

amfd: checkpoint node admin state during clm lock [#409] Amfd 
checkpoints
node admin state as lock when clm lock operation starts, but it doesn't 
send
checkpoint for the same for unlock. This doesn't allow assignment to be
given after clm unlock on payload because node remains in lock state on
newly Act Amfd. So, when Amfd marks node admin state as unlocked, Amfd
should send checkpoint to its peer.


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


Testing Commands:
-
Check the ticket.

Testing, Expected Results:
--
Payload should get assignment after unlock.

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


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net

[devel] [PATCH 0 of 1] Review Request for amfd: send commit message after async updates [#371]

2015-03-12 Thread nagendra . k
Summary: amfd: send commit message after async updates [#371]
Review request for Trac Ticket(s): #371
Peer Reviewer(s): Hans N, Praveen
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset c2364a656a6fafc13ffdd525140bb026b0fd586e
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Thu, 12 Mar 2015 12:31:26 +0530

amfd: send commit message after async updates [#371] During switchover, 
if
payload is being stopped, Standby Amfd crashes in avd_dec_warm_sync_rsp
because of counter mismatch. Counter mismatch happens because newly Act 
Amfd
updates its own counters in avd_node_failover in
handle_event_in_failover_state, and sends it to its Standby peer, but it
doesn't send AVSV_SYNC_COMMIT to its Standby peer. Once 
AVSV_SYNC_COMMIT is
received by Standby Amfd, it processes those messages and updates its 
ounter
and become in sync with Act Amfd. Since Act Amfd has updated counter and
AVSV_SYNC_COMMIT is not sent, Standby Amfd has older counters. Now, if 
warm
sync request comes at Act Amfd at this point of time, then Act Amfd 
fills
updated counter and sends it to Standby Amfd. Now, Standby Amfd receives
warn sync message and compares them with its own counter, which is 
older,
because it has not processed those aync update as Act Amfd didn't send
AVSV_SYNC_COMMIT message. Since counters will be out of sync and Standby
Amfd will crash.

So, if Act Amfd sends AVSV_SYNC_COMMIT message, Standby Amfd will 
process
sync updates and will have its counters updated. This will avoid 
counters
mismatch at Standby Amfd and will avoid the crash.


Complete diffstat:
--
 osaf/services/saf/amf/amfd/main.cc |  6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)


Testing Commands:
-
Configure AVSV_HB_PERIOD as 30 sec in /etc/opensaf/amfd.conf at 
SC-2 and set NCS_MBCSV_OBJ_TMR_WSYNC as 10 sec by calling avsv_mbcsv_obj_set()
in both Amfd as below:
diff --git a/osaf/services/saf/amf/amfd/chkop.cc 
b/osaf/services/saf/amf/amfd/chkop.cc
--- a/osaf/services/saf/amf/amfd/chkop.cc
+++ b/osaf/services/saf/amf/amfd/chkop.cc
@@ -97,6 +97,8 @@ uint32_t avsv_mbcsv_register(AVD_CL_CB *

if (NCSCC_RC_SUCCESS != (status = avsv_mbcsv_open_ckpt(cb)))
goto done_final;
+if (NCSCC_RC_SUCCESS != (status = 
avsv_mbcsv_obj_set(cb,NCS_MBCSV_OBJ_TMR_WSYNC, 1100)))
+goto done_final;

/*
 * Get MBCSv selection object.

1. Start 2 controllers(SC-2 as Standby) and one payload.
2. When Standby sends HB message to Amfnd, then perform controller
   switchover and stop payload.

Newly Standby Amfd will crash.

Testing, Expected Results:
--
Standby Amfd will not crash.

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 

[devel] [PATCH 0 of 1] Review Request for amfd: add mutex to sync up among amfd threads [#405, #707]

2015-02-25 Thread nagendra . k
Summary: amfd: add mutex to sync up among amfd threads [#405, #707]
Review request for Trac Ticket(s): #405, #707
Peer Reviewer(s): Hans N, Mathi, Praveen, Anders Bj, Anders Widell
Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE
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):
-
 EXPLAIN/COMMENT THE PATCH SERIES HERE

changeset 8cf4e73e0bf50ed7200401572d41005201626d3d
Author: Nagendra Kumarnagendr...@oracle.com
Date:   Thu, 26 Feb 2015 11:48:43 +0530

amfd: add mutex to sync up among amfd threads [#405, #707] If imm 
returns
BAD HANDLE to Amf, Amf reinitializes with imm intf in a separate 
thread. If
role change event comes during imm intf initialization time, ImplSet,
ImplClear, etc fails with BAD HANDLE.

So, Amf need to take mutex and wait for imm intf initialization.


Complete diffstat:
--
 osaf/services/saf/amf/amfd/imm.cc  |   30 -
 osaf/services/saf/amf/amfd/role.cc |  117 
--
 2 files changed, 125 insertions(+), 22 deletions(-)


Testing Commands:
-
Test Scenarios of #405 and #707.


Testing, Expected Results:
--
No crash of Amfd.

Conditions of Submission:
-
Ack from 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.


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Opensaf-devel mailing list

  1   2   3   >