Re: [devel] [PATCH 1/1] imm: Clear mLastResult before sending response to agent [#2470]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2017/05/29 04:04 PM, Hung Nguyen wrote:

In immnd_evt_proc_search_next(), before jumping to agent_rsp, mLastResult must 
be cleared.
So that it will not be freed again in immnd_proc_imma_discard_connection().
---
  src/imm/immnd/immnd_evt.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/src/imm/immnd/immnd_evt.c b/src/imm/immnd/immnd_evt.c
index cacf4d5..3f8ef10 100644
--- a/src/imm/immnd/immnd_evt.c
+++ b/src/imm/immnd/immnd_evt.c
@@ -1844,6 +1844,7 @@ static uint32_t immnd_evt_proc_search_next(IMMND_CB *cb, 
IMMND_EVT *evt,
/*Fetch client node for OI ! */
immnd_client_node_get(cb, implHandle, _cl_node);
if (oi_cl_node == NULL || oi_cl_node->mIsStale) {
+   immModel_clearLastResult(sn->searchOp);
LOG_WA(
"ERR_NO_RESOURCES: SearchNext: Implementer died 
during fetch of pure RTA");
error = SA_AIS_ERR_NO_RESOURCES;
@@ -1856,6 +1857,7 @@ static uint32_t immnd_evt_proc_search_next(IMMND_CB *cb, 
IMMND_EVT *evt,
cb, NCSMDS_SVC_ID_IMMA_OI,
oi_cl_node->agent_mds_dest,
_evt) != NCSCC_RC_SUCCESS) {
+   immModel_clearLastResult(sn->searchOp);
LOG_WA(
"ERR_NO_RESOURCES: SearchNext - Agent 
upcall over MDS for rtUpdate failed");
error = SA_AIS_ERR_NO_RESOURCES;
@@ -1884,6 +1886,7 @@ static uint32_t immnd_evt_proc_search_next(IMMND_CB *cb, 
IMMND_EVT *evt,
rc = immnd_mds_msg_send(cb, NCSMDS_SVC_ID_IMMND,
implDest, _evt);
if (rc != NCSCC_RC_SUCCESS) {
+   immModel_clearLastResult(sn->searchOp);
LOG_ER(
"ERR_NO_RESOURCES: SearchNext - Problem in 
sending to peer IMMND over MDS. Aborting searchNext.");
error = SA_AIS_ERR_NO_RESOURCES;



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

Re: [devel] [PATCH 0/1] Review Request for smf: try to wait for opensafd status before executing reboot [#2464]

[Neelakanta Reddy]

Hi Rafael,

Reviewed the patch.
Ack.

/Neel.

On 2017/05/19 05:47 PM, Rafael Odzakow wrote:
> Summary: smf: try to wait for opensafd status before executing reboot [#2464]
> Review request for Ticket(s): 2464
> Peer Reviewer(s): lennart, reddy
> Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
> Affected branch(es): develop
> Development branch: ticket-2464
> Base revision: a2798cef6b42f6c000d5bc0d4b9593eca367ea87
> Personal repository: git://git.code.sf.net/u/erafodz/review
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesn
>   OpenSAF servicesy
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
> *** EXPLAIN/COMMENT THE PATCH SERIES HERE ***
>
> revision 941789f355fccca2d547d09c5710c664b3a61dba
> Author:   Rafael Odzakow 
> Date: Fri, 19 May 2017 14:11:34 +0200
>
> smf: try to wait for opensafd status before executing reboot [#2464]
>
> There are cases when opensafd startup is still ongoing and SMF will send
> out a reboot command for a node. Because opensafd has taken a lock the
> reboot command will not be able to call opensafd stop. It is suggested
> that SMF tries to wait for the release of the lock with "opensafd
> status". The waiting time is short and SMF continues with reboot even if
> the lock is not released.
>
> ticket #2459 allows SMF to query the status of opensafd.
>
> - Refactor smf remote command to have two versions, one that logs errors of
>the endpoint command and one without error logging.
>
>
>
> Complete diffstat:
> --
>   src/smf/smfd/SmfUpgradeStep.cc |  23 ++
>   src/smf/smfd/smfd_smfnd.c  | 102 
> +
>   src/smf/smfd/smfd_smfnd.h  |   4 ++
>   3 files changed, 90 insertions(+), 39 deletions(-)
>
>
> Testing Commands:
> -
> *** LIST THE COMMAND LINE TOOLS/STEPS TO TEST YOUR CHANGES ***
>
>
> Testing, Expected Results:
> --
> *** PASTE COMMAND OUTPUTS / TEST RESULTS ***
>
>
> Conditions of Submission:
> -
> *** HOW MANY DAYS BEFORE PUSHING, CONSENSUS ETC ***
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.gitconfig file (i.e. user.name, user.email 
> etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the 

Re: [devel] [PATCH 1/1] imm: Clear dead IMMND info before switching to ACTIVE role [#2418]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2017/05/17 01:23 PM, Hung Nguyen wrote:
> During cold-sync, standby IMMD may receive info of dead IMMND.
> Before switching to active, the IMMD should clear those dead IMMND info.
> ---
>   src/imm/immd/immd_amf.c |  5 +
>   src/imm/immd/immd_cb.h  |  2 +-
>   src/imm/immd/immd_db.c  | 25 +++--
>   src/imm/immd/immd_evt.c |  3 +++
>   4 files changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/src/imm/immd/immd_amf.c b/src/imm/immd/immd_amf.c
> index 82b933f..bd29faf 100644
> --- a/src/imm/immd/immd_amf.c
> +++ b/src/imm/immd/immd_amf.c
> @@ -250,6 +250,11 @@ static void immd_saf_csi_set_cb(SaInvocationT invocation,
>   }
>   
>   if (role_change) {
> + if (new_haState == SA_AMF_HA_ACTIVE) {
> + /* Cleanup dead IMMND nodes during coldsync */
> + immd_immnd_info_tree_cleanup(cb, true);
> + }
> +
>   if (was_fully_initialized == true) {
>   if ((rc = immd_mds_change_role(cb)) !=
>   NCSCC_RC_SUCCESS) {
> diff --git a/src/imm/immd/immd_cb.h b/src/imm/immd/immd_cb.h
> index 2fc6264..3295e54 100644
> --- a/src/imm/immd/immd_cb.h
> +++ b/src/imm/immd/immd_cb.h
> @@ -171,7 +171,7 @@ void immd_immnd_info_node_getnext(NCS_PATRICIA_TREE 
> *immnd_tree, MDS_DEST *dest,
>   uint32_t immd_immnd_info_node_delete(IMMD_CB *cb,
>IMMD_IMMND_INFO_NODE *immnd_info_node);
>   
> -void immd_immnd_info_tree_cleanup(IMMD_CB *cb);
> +void immd_immnd_info_tree_cleanup(IMMD_CB *cb, bool dead_only);
>   
>   void immd_immnd_info_tree_destroy(IMMD_CB *cb);
>   
> diff --git a/src/imm/immd/immd_db.c b/src/imm/immd/immd_db.c
> index d914c9c..81a8fdd 100644
> --- a/src/imm/immd/immd_db.c
> +++ b/src/imm/immd/immd_db.c
> @@ -218,24 +218,29 @@ uint32_t immd_immnd_info_node_delete(IMMD_CB *cb,
> Arguments : IMMD_CB *cb - IMMD Control Block.
> Return Values : None
>   
> /
> -void immd_immnd_info_tree_cleanup(IMMD_CB *cb)
> +void immd_immnd_info_tree_cleanup(IMMD_CB *cb, bool dead_only)
>   {
>   IMMD_IMMND_INFO_NODE *immnd_info_node;
> - NODE_ID key;
> -
> - memset(, 0, sizeof(NODE_ID));
>   
>   /* Get the First Node */
>   immnd_info_node = (IMMD_IMMND_INFO_NODE *)ncs_patricia_tree_getnext(
> - >immnd_tree, (uint8_t *));
> + >immnd_tree, (uint8_t *)NULL);
>   while (immnd_info_node) {
> - key = m_NCS_NODE_ID_FROM_MDS_DEST(immnd_info_node->immnd_dest);
> -
> - immd_immnd_info_node_delete(cb, immnd_info_node);
> + NODE_ID key = m_NCS_NODE_ID_FROM_MDS_DEST(
> + immnd_info_node->immnd_dest);
> + NODE_ID* key_pointer = 
> +
> + if (!dead_only || !immnd_info_node->isUp) {
> + LOG_NO("Deleting IMMND dest:%" PRIu64,
> +immnd_info_node->immnd_dest);
> + immd_immnd_info_node_delete(cb, immnd_info_node);
> + /* Reset iteration */
> + key_pointer = NULL;
> + }
>   
>   immnd_info_node =
>   (IMMD_IMMND_INFO_NODE *)ncs_patricia_tree_getnext(
> - >immnd_tree, (uint8_t *));
> + >immnd_tree, (uint8_t *)key_pointer);
>   }
>   
>   return;
> @@ -253,7 +258,7 @@ void immd_immnd_info_tree_destroy(IMMD_CB *cb)
>   return;
>   
>   /* cleanup the client tree */
> - immd_immnd_info_tree_cleanup(cb);
> + immd_immnd_info_tree_cleanup(cb, false);
>   
>   /* destroy the tree */
>   ncs_patricia_tree_destroy(>immnd_tree);
> diff --git a/src/imm/immd/immd_evt.c b/src/imm/immd/immd_evt.c
> index adac747..24a4185 100644
> --- a/src/imm/immd/immd_evt.c
> +++ b/src/imm/immd/immd_evt.c
> @@ -2966,6 +2966,9 @@ static uint32_t immd_evt_proc_rda_callback(IMMD_CB *cb, 
> IMMD_EVT *evt)
>   
>   LOG_NO("ACTIVE request");
>   
> + /* Cleanup dead IMMND nodes during coldsync */
> + immd_immnd_info_tree_cleanup(cb, true);
> +
>   if (was_fully_initialized == true) {
>   if ((rc = immd_mds_change_role(cb)) !=
>   NCSCC_RC_SUCCESS) {


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

Re: [devel] [PATCH 1/1] imm: change log level to warning for "ER Problem in sending to IMMD over MDS" [#2465]

[Neelakanta Reddy]

Hi Zoran,

Reviewed the patch.
Ack.

/Neel.

On 2017/05/19 06:13 PM, Zoran Milinkovic wrote:
> Log level for message "ER Problem in sending to IMMD over MDS" is changed 
> from error to warning.
> ---
>   src/imm/immnd/immnd_evt.c | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/imm/immnd/immnd_evt.c b/src/imm/immnd/immnd_evt.c
> index cacf4d5..21d8671 100644
> --- a/src/imm/immnd/immnd_evt.c
> +++ b/src/imm/immnd/immnd_evt.c
> @@ -2939,7 +2939,7 @@ static uint32_t immnd_evt_proc_impl_set(IMMND_CB *cb, 
> IMMND_EVT *evt,
>   NULL; /*precaution. */
>   
>   if (rc != NCSCC_RC_SUCCESS) {
> - LOG_ER("Problem in sending to IMMD over MDS");
> + LOG_WA("Problem in sending to IMMD over MDS");
>   send_evt.info.imma.info.implSetRsp.error = SA_AIS_ERR_TRY_AGAIN;
>   cb->fevs_replies_pending--;
>   goto agent_rsp;
> @@ -3055,7 +3055,7 @@ static uint32_t immnd_evt_proc_ccb_init(IMMND_CB *cb, 
> IMMND_EVT *evt,
>   _evt);
>   
>   if (rc != NCSCC_RC_SUCCESS) {
> - LOG_ER("Problem in sending ro IMMD over MDS");
> + LOG_WA("Problem in sending to IMMD over MDS");
>   send_evt.info.imma.info.ccbInitRsp.error = SA_AIS_ERR_TRY_AGAIN;
>   cb->fevs_replies_pending--;
>   goto agent_rsp;
> @@ -3199,7 +3199,7 @@ static uint32_t immnd_evt_proc_rt_update(IMMND_CB *cb, 
> IMMND_EVT *evt,
>   cb->immd_mdest_id, _evt);
>   
>   if (rc != NCSCC_RC_SUCCESS) {
> - LOG_ER("Problem in sending to IMMD over MDS");
> + LOG_WA("Problem in sending to IMMD over MDS");
>   err = SA_AIS_ERR_TRY_AGAIN;
>   cb->fevs_replies_pending--;
>   goto agent_rsp;


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

Re: [devel] [PATCH 1/1] imm: Discard Adm Impl continuation when peer IMMND is down [#2461]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2017/05/17 01:10 PM, Hung Nguyen wrote:
> Discard Adm Impl continuation when peer IMMND is down.
> ---
>   src/imm/immnd/ImmModel.cc | 24 
>   1 file changed, 24 insertions(+)
>
> diff --git a/src/imm/immnd/ImmModel.cc b/src/imm/immnd/ImmModel.cc
> index 56d8c8d..25f8621 100644
> --- a/src/imm/immnd/ImmModel.cc
> +++ b/src/imm/immnd/ImmModel.cc
> @@ -13804,6 +13804,7 @@ void ImmModel::discardNode(unsigned int deadNode, 
> IdVector& cv, IdVector& gv,
> CcbVector::iterator i3;
> ConnVector implv;
> ConnVector::iterator i4;
> +  ContinuationMap3::iterator ci3;
> TRACE_ENTER();
>   
> if (sImmNodeState == IMM_NODE_W_AVAILABLE) {
> @@ -13923,6 +13924,29 @@ void ImmModel::discardNode(unsigned int deadNode, 
> IdVector& cv, IdVector& gv,
> osafassert((*i3)->mOriginatingConn == 0);  // Dead node can not be 
> us!!
>   }
> }
> +
> +  /* Discard Adm Impl continuation */
> +  for (ci3 = sAdmImplContinuationMap.begin();
> +   ci3 != sAdmImplContinuationMap.end();) {
> +if (m_NCS_NODE_ID_FROM_MDS_DEST(ci3->second.mReply_dest) == deadNode) {
> +  TRACE_5("Discarding Adm Impl continuation %llu", ci3->first);
> +  ci3 = sAdmImplContinuationMap.erase(ci3);
> +} else {
> +  ++ci3;
> +}
> +  }
> +
> +  /* Discard Search Impl continuation */
> +  for (ci3 = sSearchImplContinuationMap.begin();
> +   ci3 != sSearchImplContinuationMap.end();) {
> +if (m_NCS_NODE_ID_FROM_MDS_DEST(ci3->second.mReply_dest) == deadNode) {
> +  TRACE_5("Discarding Search Impl continuation %llu", ci3->first);
> +  ci3 = sSearchImplContinuationMap.erase(ci3);
> +} else {
> +  ++ci3;
> +}
> +  }
> +
> TRACE_LEAVE();
>   }
>   


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

Re: [devel] [PATCH 1/1] imm: Skip sending re-intro message if IMMD is not up [#2447]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2017/05/09 01:58 PM, Hung Nguyen wrote:
> Skip sending re-intro message if IMMD is not up.
> ---
>   src/imm/immnd/immnd_mds.c  | 1 +
>   src/imm/immnd/immnd_proc.c | 6 ++
>   2 files changed, 7 insertions(+)
>
> diff --git a/src/imm/immnd/immnd_mds.c b/src/imm/immnd/immnd_mds.c
> index 76ba77a..dd5ca83 100644
> --- a/src/imm/immnd/immnd_mds.c
> +++ b/src/imm/immnd/immnd_mds.c
> @@ -593,6 +593,7 @@ static uint32_t immnd_mds_svc_evt(IMMND_CB *cb,
>   case NCSMDS_DOWN:
>   TRACE("IMMD SERVICE DOWN => CLUSTER GOING DOWN");
>   cb->fevs_replies_pending = 0;
> + cb->is_immd_up = false;
>   break;
>   
>   case NCSMDS_UP:
> diff --git a/src/imm/immnd/immnd_proc.c b/src/imm/immnd/immnd_proc.c
> index 74cd24f..2bba717 100644
> --- a/src/imm/immnd/immnd_proc.c
> +++ b/src/imm/immnd/immnd_proc.c
> @@ -494,6 +494,12 @@ uint32_t immnd_introduceMe(IMMND_CB *cb)
>   memset(_evt, '\0', sizeof(IMMSV_EVT));
>   
>   if (cb->mIntroduced == 2) {
> + /* Skip sending if IMMD is not up */
> + if (!cb->is_immd_up) {
> + TRACE("IMMD is not up, skip sending re-intro message");
> + rc = NCSCC_RC_FAILURE;
> + goto error;
> + }
>   /* Check for syncPid and pbePid, intro message will not be sent
>* until they all exit */
>   if (cb->syncPid > 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

Re: [devel] [PATCH 1/1] imm: Remove CcbErrStrings that are set only on nodes with OI/PBE [#2446]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2017/05/09 01:45 PM, Hung Nguyen wrote:
> Remove CcbErrStrings that are set only on nodes with OI/PBE.
> Abort the CCB when those errors occur to avoid taking long time to abort the 
> CCB (due to timeout).
> ---
>   src/imm/immnd/immnd_evt.c | 68 
> ---
>   1 file changed, 17 insertions(+), 51 deletions(-)
>
> diff --git a/src/imm/immnd/immnd_evt.c b/src/imm/immnd/immnd_evt.c
> index 872bc62..eba29da 100644
> --- a/src/imm/immnd/immnd_evt.c
> +++ b/src/imm/immnd/immnd_evt.c
> @@ -7116,9 +7116,6 @@ static void immnd_evt_proc_object_create(IMMND_CB *cb, 
> IMMND_EVT *evt,
>  should prevent any apply to succeed.
>   */
>   err = SA_AIS_ERR_FAILED_OPERATION;
> - immModel_setCcbErrorString(
> - cb, evt->info.objCreate.ccbId,
> - IMM_RESOURCE_ABORT "PBE is down");
>   immnd_proc_global_abort_ccb(cb,
>   evt->info.objCreate.ccbId);
>   } else {
> @@ -7143,10 +7140,6 @@ static void immnd_evt_proc_object_create(IMMND_CB *cb, 
> IMMND_EVT *evt,
>   LOG_ER("Upcall over MDS for ccbObjectCreate "
>  "to PBE failed! - aborting");
>   err = SA_AIS_ERR_FAILED_OPERATION;
> - immModel_setCcbErrorString(
> - cb, evt->info.objCreate.ccbId,
> - IMM_RESOURCE_ABORT
> - "Upcall over MDS to PBE failed");
>   immnd_proc_global_abort_ccb(
>   cb, evt->info.objCreate.ccbId);
>   }
> @@ -7169,9 +7162,8 @@ static void immnd_evt_proc_object_create(IMMND_CB *cb, 
> IMMND_EVT *evt,
>   LOG_WA("Client died");
>   err = SA_AIS_ERR_FAILED_OPERATION;
>   delayedReply = false;
> - immModel_setCcbErrorString(
> - cb, evt->info.objCreate.ccbId,
> - IMM_RESOURCE_ABORT "Client died");
> + immnd_proc_global_abort_ccb(
> + cb, evt->info.objCreate.ccbId);
>   } else {
>   memset(_evt, '\0', sizeof(IMMSV_EVT));
>   send_evt.type = IMMSV_EVT_TYPE_IMMA;
> @@ -7202,10 +7194,8 @@ static void immnd_evt_proc_object_create(IMMND_CB *cb, 
> IMMND_EVT *evt,
>   LOG_ER(
>   "Agent upcall over MDS for 
> ccbObjectCreate failed");
>   err = SA_AIS_ERR_FAILED_OPERATION;
> - immModel_setCcbErrorString(
> - cb, evt->info.objCreate.ccbId,
> - IMM_RESOURCE_ABORT
> - "Agent upcall over MDS failed");
> + immnd_proc_global_abort_ccb(
> + cb, evt->info.objCreate.ccbId);
>   }
>   }
>   }
> @@ -7409,9 +7399,6 @@ static void immnd_evt_proc_object_modify(IMMND_CB *cb, 
> IMMND_EVT *evt,
>  should prevent any apply to succeed.
>   */
>   err = SA_AIS_ERR_FAILED_OPERATION;
> - immModel_setCcbErrorString(
> - cb, evt->info.objModify.ccbId,
> - IMM_RESOURCE_ABORT "PBE is down");
>   immnd_proc_global_abort_ccb(cb,
>   evt->info.objModify.ccbId);
>   } else {
> @@ -7441,10 +7428,6 @@ static void immnd_evt_proc_object_modify(IMMND_CB *cb, 
> IMMND_EVT *evt,
>   LOG_ER("Upcall over MDS for ccbObjectModify "
>  "to PBE failed! - aborting");
>   err = SA_AIS_ERR_FAILED_OPERATION;
> - immModel_setCcbErrorString(
> - cb, evt->info.objModify.ccbId,
> - IMM_RESOURCE_ABORT
> - "Upcall over MDS to PBE failed");
>   immnd_proc_global_abort_ccb(
>   cb, evt->info.objModify.ccbId);
>   }
> @@ -7469,9 +7452,8 @@ static void immnd_evt_proc_object_modify(IMMND_CB *cb, 
> IMMND_EVT *evt,
>   "OI Client went down so no modify upcall");
>   err = 

Re: [devel] smf: Expalain how osafAmfRestrictAutoRepairEnable setting in AMF affects SMF [#2379]

[Neelakanta Reddy]

Hi Lennart,

I did not see any mention related to "#2144 AMF: support restrictions to 
auto-repair" in AMF PR.
can you point to a section in AMF_PR?

Thanks,
Neel.

On 2017/05/04 04:13 PM, Lennart Lund wrote:
> Document review for OpenSAF_SMFSv_PR document
>
> smf: Expalain how osafAmfRestrictAutoRepairEnable setting in AMF affects SMF
>
> Updated document attached
>
> Will be pushed after ack from reviewers or latest end of next week
>
> Thanks
> Lennart


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

Re: [devel] [PATCH 1/1] smf: Attribute value handling in longDn applier is incorrect [#2442]

[Neelakanta Reddy]

Hi Leenart,

Yes, push the patch, with all #2442 changes.
Reviewed and tested the patch.
Ack.

/Neel.

On 2017/04/27 07:40 PM, Lennart Lund wrote:
> Hi Neel,
>
> I am not sure I understand what you mean?
> All of the #2442 changes are needed not only the "> +  attribute = 
> attrMod->modAttr;" fix.
> I suggest that you push your  #2431 patch as is after the #2442 fix is pushed
>
> Thanks
> Lennart
>   
>> -Original Message-
>> From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
>> Sent: den 27 april 2017 15:59
>> To: Lennart Lund <lennart.l...@ericsson.com>; Rafael Odzakow
>> <rafael.odza...@ericsson.com>
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [PATCH 1/1] smf: Attribute value handling in longDn applier is
>> incorrect [#2442]
>>
>> Hi Lennart,
>>
>>   From IMM Version A.2.17, the IMM modify callback will have canonical
>> attributes.
>> All the attributes in the class along with the modified attributes.
>>
>> The code in CcbApplyCallback in the file
>> "src/smf/smfd/SmfImmApplierHdl.cc", if the attrmods are more than one
>> then the following correction has to be made:
>>
>> diff --git a/src/smf/smfd/SmfImmApplierHdl.cc
>> b/src/smf/smfd/SmfImmApplierHdl.cc
>> --- a/src/smf/smfd/SmfImmApplierHdl.cc
>> +++ b/src/smf/smfd/SmfImmApplierHdl.cc
>> @@ -455,6 +455,7 @@ static void CcbApplyCallback(SaImmOiHand
>>if (attribute_name_.compare(attribute.attrName) != 0) {
>>  // Not found
>>  attrMod = opdata->param.modify.attrMods[i];
>> +  attribute = attrMod->modAttr;
>>  continue;
>>}
>>
>>
>> I tested with A.2.17 IMM version, the longdns are working fine.. If you
>> agree with the above patch, re-publish the patch.
>> The #2442 has to go before #2431.
>>
>> Thanks,
>> Neel.
>>
>>
>> On 2017/04/27 06:40 PM, Lennart Lund wrote:
>>> SMF has an IMM applier to track changes of attribute longDnsAllowed in
>> OpensafImm class.
>>> Fix that the applier does not find the value if the list of attributes to be
>> handled in the
>>> apply callback contains more than one attribute. Also if the found attribute
>> is not the serached
>>> one the cached attribute value is set to invalid
>>> ---
>>>src/smf/smfd/SmfImmApplierHdl.cc | 28 +++-
>>>1 file changed, 15 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/src/smf/smfd/SmfImmApplierHdl.cc
>> b/src/smf/smfd/SmfImmApplierHdl.cc
>>> index d325ec4..693446b 100644
>>> --- a/src/smf/smfd/SmfImmApplierHdl.cc
>>> +++ b/src/smf/smfd/SmfImmApplierHdl.cc
>>> @@ -436,15 +436,12 @@ static void CcbApplyCallback(SaImmOiHandleT
>> immOiHandle, SaImmOiCcbIdT ccbId) {
>>>  objName = osaf_extended_name_borrow(>objectName);
>>>  if (object_name_.compare(objName) != 0) {
>>> -TRACE("%s: Object \"%s\" not an OpensafConfig object",
>> __FUNCTION__,
>>> -  objName);
>>> +LOG_NO("%s: Object \"%s\" wrong object", __FUNCTION__,
>> objName);
>>>goto done;
>>>  }
>>>
>>> -  /* Read value in opensafNetworkName
>>> -   * Note: This is implemented as a loop in case more attributes are
>>> -   *   added in the class in the future. For now the only
>>> -   *   attribute of interest here is opensafNetworkName
>>> +  /* Read value
>>> +   * Note: For now the only attribute of interest here is
>> opensafNetworkName
>>>   */
>>>  TRACE("%s: Read value in attributes", __FUNCTION__);
>>>  attrMod = opdata->param.modify.attrMods[0];
>>> @@ -455,21 +452,26 @@ static void CcbApplyCallback(SaImmOiHandleT
>> immOiHandle, SaImmOiCcbIdT ccbId) {
>>>if (attribute_name_.compare(attribute.attrName) != 0) {
>>>  // Not found
>>>  attrMod = opdata->param.modify.attrMods[i];
>>> +  attribute = attrMod->modAttr;
>>>  continue;
>>>}
>>>
>>>// Attribute found
>>>value = static_cast(attribute.attrValues[0]);
>>> +TRACE("Attribute found: attrName '%s', value = %d",
>>> +  attribute.attrName, *value);
>>>break;
>>>  }
>>>
>>> -  if (value == nullptr) {
>>> -TRACE("%s: Value is nullptr", __FUNCTION__);
>>>

Re: [devel] [PATCH 1/1] smf: Attribute value handling in longDn applier is incorrect [#2442]

[Neelakanta Reddy]

Hi Lennart,

 From IMM Version A.2.17, the IMM modify callback will have canonical 
attributes.
All the attributes in the class along with the modified attributes.

The code in CcbApplyCallback in the file 
"src/smf/smfd/SmfImmApplierHdl.cc", if the attrmods are more than one 
then the following correction has to be made:

diff --git a/src/smf/smfd/SmfImmApplierHdl.cc 
b/src/smf/smfd/SmfImmApplierHdl.cc
--- a/src/smf/smfd/SmfImmApplierHdl.cc
+++ b/src/smf/smfd/SmfImmApplierHdl.cc
@@ -455,6 +455,7 @@ static void CcbApplyCallback(SaImmOiHand
  if (attribute_name_.compare(attribute.attrName) != 0) {
// Not found
attrMod = opdata->param.modify.attrMods[i];
+  attribute = attrMod->modAttr;
continue;
  }


I tested with A.2.17 IMM version, the longdns are working fine.. If you 
agree with the above patch, re-publish the patch.
The #2442 has to go before #2431.

Thanks,
Neel.


On 2017/04/27 06:40 PM, Lennart Lund wrote:
> SMF has an IMM applier to track changes of attribute longDnsAllowed in 
> OpensafImm class.
> Fix that the applier does not find the value if the list of attributes to be 
> handled in the
> apply callback contains more than one attribute. Also if the found attribute 
> is not the serached
> one the cached attribute value is set to invalid
> ---
>   src/smf/smfd/SmfImmApplierHdl.cc | 28 +++-
>   1 file changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/src/smf/smfd/SmfImmApplierHdl.cc 
> b/src/smf/smfd/SmfImmApplierHdl.cc
> index d325ec4..693446b 100644
> --- a/src/smf/smfd/SmfImmApplierHdl.cc
> +++ b/src/smf/smfd/SmfImmApplierHdl.cc
> @@ -436,15 +436,12 @@ static void CcbApplyCallback(SaImmOiHandleT 
> immOiHandle, SaImmOiCcbIdT ccbId) {
>   
> objName = osaf_extended_name_borrow(>objectName);
> if (object_name_.compare(objName) != 0) {
> -TRACE("%s: Object \"%s\" not an OpensafConfig object", __FUNCTION__,
> -  objName);
> +LOG_NO("%s: Object \"%s\" wrong object", __FUNCTION__, objName);
>   goto done;
> }
>   
> -  /* Read value in opensafNetworkName
> -   * Note: This is implemented as a loop in case more attributes are
> -   *   added in the class in the future. For now the only
> -   *   attribute of interest here is opensafNetworkName
> +  /* Read value
> +   * Note: For now the only attribute of interest here is opensafNetworkName
>  */
> TRACE("%s: Read value in attributes", __FUNCTION__);
> attrMod = opdata->param.modify.attrMods[0];
> @@ -455,21 +452,26 @@ static void CcbApplyCallback(SaImmOiHandleT 
> immOiHandle, SaImmOiCcbIdT ccbId) {
>   if (attribute_name_.compare(attribute.attrName) != 0) {
> // Not found
> attrMod = opdata->param.modify.attrMods[i];
> +  attribute = attrMod->modAttr;
> continue;
>   }
>   
>   // Attribute found
>   value = static_cast(attribute.attrValues[0]);
> +TRACE("Attribute found: attrName '%s', value = %d",
> +  attribute.attrName, *value);
>   break;
> }
>   
> -  if (value == nullptr) {
> -TRACE("%s: Value is nullptr", __FUNCTION__);
> -SetAttributeValue("");
> -attribute_value_is_valid_ = false;
> -  } else {
> -SetAttributeValue(std::to_string(*value));
> -attribute_value_is_valid_ = true;
> +  if (attrMod != nullptr) {
> +if (value == nullptr) {
> +  TRACE("%s: Value is nullptr", __FUNCTION__);
> +  SetAttributeValue("");
> +  attribute_value_is_valid_ = false;
> +} else {
> +  SetAttributeValue(std::to_string(*value));
> +  attribute_value_is_valid_ = true;
> +}
> }
>   
>   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

Re: [devel] [PATCH 1/1] smf: updated the imm API vesrion to latest supported [#2431]

[Neelakanta Reddy]

Hi Lennart,

The problem is happening when the IMM OI version is greater than A.2.16.
I tested with A.2.16 its working fine.

Test with A.2.16 and let me know the result.
If the tests are passing the IMM version for 
src/smf/smfd/SmfImmApplierHdl.h will be changed to A.2.16 before pushing 
the code.

Parallely, I will debug why it is failing for version greater than A.2.16.

Thanks,
Neel.

On 2017/04/24 06:31 PM, Lennart Lund wrote:
> Hi Neel,
>
> I have an idea how to fix the problem (2.).
> I will create an addition to your patch and test if it solves the problem. I 
> will send it to you if it works with our test
>
> /Lennart
>   
>> -Original Message-
>> From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
>> Sent: den 24 april 2017 10:20
>> To: Lennart Lund <lennart.l...@ericsson.com>; Rafael Odzakow
>> <rafael.odza...@ericsson.com>
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [PATCH 1/1] smf: updated the imm API vesrion to latest
>> supported [#2431]
>>
>> Hi Lennart,
>>
>> comments inline.
>>
>> On 2017/04/24 01:17 PM, Lennart Lund wrote:
>>> Hi Neel
>>>
>>> I have found two things:
>>> 1.
>>> You have changed SMF to use IMM minor version 17 but the IMM PR
>> document says that version 18 is the latest. Also the ticket says that SMF 
>> shall
>> be upgraded to use version 18.
>> The latest A.2.18 is for CLM integration, with IMM( as CLM Integration
>> is not happened in OpenSAF Fully).
>> so, used A,2,17 and will change to A.2.17 in ticket description.
>>> 2.
>>> I have a test that during campaign init state changes "longDnsAllowed"
>> setting to ON and then creates an object with a long name. With this patch
>> applied this is no longer working. SMF uses an IMM Applier to surveil the
>> "longDnsAllowed" attribute. With the patch applied it seems as if it takes
>> longer time for IMM to activate the applier callback that makes SMF aware of
>> that the setting has changed resulting in a "too long name" fail when SMF
>> tries to create the object. I will do some more investigations
>> changing IMM version to A.2.17 should not cause any delays, I will also
>> test the longdn related cases.
>>
>> Thanks,
>> Neel.
>>> Thanks
>>> Lennart
>>>
>>>> -Original Message-
>>>> From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
>>>> Sent: den 20 april 2017 12:59
>>>> To: Rafael Odzakow <rafael.odza...@ericsson.com>; Lennart Lund
>>>> <lennart.l...@ericsson.com>
>>>> Cc: opensaf-devel@lists.sourceforge.net; Neelakanta Reddy
>>>> <reddy.neelaka...@oracle.com>
>>>> Subject: [PATCH 1/1] smf: updated the imm API vesrion to latest
>> supported
>>>> [#2431]
>>>>
>>>> ---
>>>>src/smf/smfd/SmfCampaignThread.cc  |  2 +-
>>>>src/smf/smfd/SmfExecControlHdl.h   |  2 +-
>>>>src/smf/smfd/SmfImmApplierHdl.h|  2 +-
>>>>src/smf/smfd/SmfImmOperation.cc| 15 +--
>>>>src/smf/smfd/SmfProcedureThread.cc |  2 +-
>>>>src/smf/smfd/SmfUpgradeCampaign.cc |  2 ++
>>>>src/smf/smfd/SmfUpgradeStep.h  |  2 +-
>>>>src/smf/smfd/SmfUtils.cc   |  7 ---
>>>>src/smf/smfd/smfd_campaign_oi.cc   |  2 +-
>>>>src/smf/smfd/smfd_main.cc  |  2 +-
>>>>10 files changed, 22 insertions(+), 16 deletions(-)
>>>>
>>>> diff --git a/src/smf/smfd/SmfCampaignThread.cc
>>>> b/src/smf/smfd/SmfCampaignThread.cc
>>>> index 413beb0..8f3d257 100644
>>>> --- a/src/smf/smfd/SmfCampaignThread.cc
>>>> +++ b/src/smf/smfd/SmfCampaignThread.cc
>>>> @@ -521,7 +521,7 @@ SaAisErrorT
>>>> SmfCampaignThread::createImmHandle(SmfCampaign *i_campaign) {
>>>>  TRACE_ENTER();
>>>>  SaAisErrorT rc = SA_AIS_OK;
>>>>  int existCnt = 0;
>>>> -  SaVersionT immVersion = {'A', 2, 1};
>>>> +  SaVersionT immVersion = {'A', 2, 17};
>>>>  SmfImmUtils immutil;
>>>>  SaImmAttrValuesT_2 **attributes;
>>>>  const char *campOiName = NULL;
>>>> diff --git a/src/smf/smfd/SmfExecControlHdl.h
>>>> b/src/smf/smfd/SmfExecControlHdl.h
>>>> index 3c3e8bc..8ba30a4 100644
>>>> --- a/src/smf/smfd/SmfExecControlHdl.h
>>>> +++ b/src/smf/smfd/SmfExecControlHdl.h
>>>> @@ -108,7 +108,7 @@ c

Re: [devel] Fwd: [PATCH 1/1] smf: cli-command does not wait for nodes to start [#1969]

[Neelakanta Reddy]

   Hi Rafael,

Reviewed the patch.
Ack.

/Neel.

On 2017/04/21 01:29 PM, Rafael Odzakow wrote:
>
>
>
>
>  Forwarded Message 
> Subject:  [PATCH 1/1] smf: cli-command does not wait for nodes to 
> start [#1969]
> Date: Thu, 20 Apr 2017 15:32:23 +0200
> From: Rafael Odzakow 
> To:   lennart.l...@ericsson.com
> CC:   opensaf-devel@lists.sourceforge.net, Rafael Odzakow 
> 
>
>
>
> While doing the wrapup of a one-step upgrade with reboot the other
> controller takes extra time to come back up. Now when we have a CLI
> command in the campaign doing a operation on that missing controller the
> campaign will fail. The reason is that there is no timer to wait for
> node up. This patch uses a prexisting function with a timer that waits
> until a node comes up for 10 minutes. The time is taken from SMF
> configuration 'smfRebootTimeout'.
> ---
>   src/smf/smfd/SmfUpgradeAction.cc | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/smf/smfd/SmfUpgradeAction.cc 
> b/src/smf/smfd/SmfUpgradeAction.cc
> index f8ae58d..94c3dfd 100644
> --- a/src/smf/smfd/SmfUpgradeAction.cc
> +++ b/src/smf/smfd/SmfUpgradeAction.cc
> @@ -151,7 +151,7 @@ SaAisErrorT SmfCliCommandAction::execute(SaImmOiHandleT 
> i_oiHandle,
> for (it = m_plmExecEnvList.begin(); it != m_plmExecEnvList.end(); ++it) {
>   const std::string& n = it->getPrefered();
>   SmfndNodeDest nodeDest;
> -if (!getNodeDestination(n, , NULL, -1)) {
> +if (!waitForNodeDestination(n, )) {
> LOG_ER("SmfCliCommandAction no node destination found for node %s",
>n.c_str());
> result = SA_AIS_ERR_NOT_EXIST;
> @@ -199,7 +199,7 @@ SaAisErrorT SmfCliCommandAction::rollback(const 
> std::string& i_rollbackDn) {
> for (it = m_plmExecEnvList.rbegin(); it != m_plmExecEnvList.rend(); ++it) 
> {
>   const std::string& n = it->getPrefered();
>   SmfndNodeDest nodeDest;
> -if (!getNodeDestination(n, , NULL, -1)) {
> +if (!waitForNodeDestination(n, )) {
> LOG_ER("SmfCliCommandAction no node destination found for node %s",
>n.c_str());
> result = SA_AIS_ERR_NOT_EXIST;
> -- 
> 1.9.1
>





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

Re: [devel] [PATCH 1/1] imm: Ignore the sync'ed IMMND nodes that are not up [#2418]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2017/04/13 02:22 PM, Hung Nguyen wrote:
> Add new 'isUp' flag to IMMD_IMMND_INFO_NODE.
> If a new IMMND node is added during MDS UP event or intro message,
> the flag is set to true.
> If a new IMMND node is added during coldsync, the flag is set to false.
> The flag will be set to true when MDS UP event comes.
> ---
>   src/imm/immd/immd_cb.h|  1 +
>   src/imm/immd/immd_db.c| 34 +-
>   src/imm/immd/immd_evt.c   |  2 ++
>   src/imm/immd/immd_mbcsv.c |  5 +
>   4 files changed, 29 insertions(+), 13 deletions(-)
>
> diff --git a/src/imm/immd/immd_cb.h b/src/imm/immd/immd_cb.h
> index af63a98..09a9c2c 100644
> --- a/src/imm/immd/immd_cb.h
> +++ b/src/imm/immd/immd_cb.h
> @@ -59,6 +59,7 @@ typedef struct immd_immnd_info_node {
> bool isCoord;
> bool syncStarted;
> bool pbeConfigured; /* Pbe-file-name configured. Pbe may still be 
> disabled. */
> +  bool isUp; /* True if received the MDS UP event */
>   } IMMD_IMMND_INFO_NODE;
>   
>   typedef struct immd_immnd_detached_node { /* IMMD SBY tracking of departed
> diff --git a/src/imm/immd/immd_db.c b/src/imm/immd/immd_db.c
> index 7968b07..ec005d9 100644
> --- a/src/imm/immd/immd_db.c
> +++ b/src/imm/immd/immd_db.c
> @@ -80,20 +80,28 @@ uint32_t immd_immnd_info_node_get(NCS_PATRICIA_TREE 
> *immnd_tree, MDS_DEST *dest,
>   void immd_immnd_info_node_getnext(NCS_PATRICIA_TREE *immnd_tree, MDS_DEST 
> *dest,
> IMMD_IMMND_INFO_NODE **immnd_info_node)
>   {
> - NODE_ID key;
> - memset(, 0, sizeof(NODE_ID));
> - /* Fill the Key */
> -
> - if (dest) {
> - key = m_NCS_NODE_ID_FROM_MDS_DEST((*dest));
> + IMMD_IMMND_INFO_NODE* next_node = NULL;
> + MDS_DEST* current_dest = dest;
> + do {
> + if (current_dest) {
> + NODE_ID key;
> + memset(, 0, sizeof(NODE_ID));
> + key = m_NCS_NODE_ID_FROM_MDS_DEST((*current_dest));
> +
> + next_node =
> + (IMMD_IMMND_INFO_NODE *)ncs_patricia_tree_getnext(
> + immnd_tree, (uint8_t *));
> + if (next_node) {
> + current_dest = _node->immnd_dest;
> + }
> + } else {
> + next_node =
> + (IMMD_IMMND_INFO_NODE *)ncs_patricia_tree_getnext(
> + immnd_tree, (uint8_t *)NULL);
> + }
> + } while (next_node && !next_node->isUp);
>   
> - *immnd_info_node =
> - (IMMD_IMMND_INFO_NODE *)ncs_patricia_tree_getnext(
> - immnd_tree, (uint8_t *));
> - } else
> - *immnd_info_node =
> - (IMMD_IMMND_INFO_NODE *)ncs_patricia_tree_getnext(
> - immnd_tree, (uint8_t *)NULL);
> + *immnd_info_node = next_node;
>   
>   return;
>   }
> diff --git a/src/imm/immd/immd_evt.c b/src/imm/immd/immd_evt.c
> index 49ac7c3..c1371fc 100644
> --- a/src/imm/immd/immd_evt.c
> +++ b/src/imm/immd/immd_evt.c
> @@ -1054,6 +1054,8 @@ static IMMD_IMMND_INFO_NODE 
> *immd_add_immnd_node(IMMD_CB *cb, MDS_DEST dest)
>   return NULL;
>   }
>   
> + node_info->isUp = true;
> +
>   if (add_flag) {
>   TRACE("IMMND node has already been added, dest %" PRIu64, dest);
>   }
> diff --git a/src/imm/immd/immd_mbcsv.c b/src/imm/immd/immd_mbcsv.c
> index 8ccadd1..bed2c28 100644
> --- a/src/imm/immd/immd_mbcsv.c
> +++ b/src/imm/immd/immd_mbcsv.c
> @@ -1243,6 +1243,11 @@ static uint32_t mbcsv_dec_sync_resp(IMMD_CB *cb, 
> NCS_MBCSV_CB_ARG *arg)
>   immd_immnd_info_node_find_add(>immnd_tree, ,
> _info, _flag);
>   osafassert(node_info);
> + if (!add_flag) {
> + /* New node is added to the list,
> +  * MDS UP event is not received */
> + node_info->isUp = false;
> + }
>   
>   ptr = ncs_dec_flatten_space(>info.decode.i_uba, data,
>   sizeof(uint32_t));


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

Re: [devel] [PATCH 1/1] smf: updated the imm API vesrion to latest supported [#2431]

[Neelakanta Reddy]

Hi Lennart,

comments inline.

On 2017/04/24 01:17 PM, Lennart Lund wrote:
> Hi Neel
>
> I have found two things:
> 1.
> You have changed SMF to use IMM minor version 17 but the IMM PR document says 
> that version 18 is the latest. Also the ticket says that SMF shall be 
> upgraded to use version 18.
The latest A.2.18 is for CLM integration, with IMM( as CLM Integration 
is not happened in OpenSAF Fully).
so, used A,2,17 and will change to A.2.17 in ticket description.
> 2.
> I have a test that during campaign init state changes "longDnsAllowed" 
> setting to ON and then creates an object with a long name. With this patch 
> applied this is no longer working. SMF uses an IMM Applier to surveil the 
> "longDnsAllowed" attribute. With the patch applied it seems as if it takes 
> longer time for IMM to activate the applier callback that makes SMF aware of 
> that the setting has changed resulting in a "too long name" fail when SMF 
> tries to create the object. I will do some more investigations
changing IMM version to A.2.17 should not cause any delays, I will also 
test the longdn related cases.

Thanks,
Neel.
> Thanks
> Lennart
>
>> -Original Message-
>> From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
>> Sent: den 20 april 2017 12:59
>> To: Rafael Odzakow <rafael.odza...@ericsson.com>; Lennart Lund
>> <lennart.l...@ericsson.com>
>> Cc: opensaf-devel@lists.sourceforge.net; Neelakanta Reddy
>> <reddy.neelaka...@oracle.com>
>> Subject: [PATCH 1/1] smf: updated the imm API vesrion to latest supported
>> [#2431]
>>
>> ---
>>   src/smf/smfd/SmfCampaignThread.cc  |  2 +-
>>   src/smf/smfd/SmfExecControlHdl.h   |  2 +-
>>   src/smf/smfd/SmfImmApplierHdl.h|  2 +-
>>   src/smf/smfd/SmfImmOperation.cc| 15 +--
>>   src/smf/smfd/SmfProcedureThread.cc |  2 +-
>>   src/smf/smfd/SmfUpgradeCampaign.cc |  2 ++
>>   src/smf/smfd/SmfUpgradeStep.h  |  2 +-
>>   src/smf/smfd/SmfUtils.cc   |  7 ---
>>   src/smf/smfd/smfd_campaign_oi.cc   |  2 +-
>>   src/smf/smfd/smfd_main.cc  |  2 +-
>>   10 files changed, 22 insertions(+), 16 deletions(-)
>>
>> diff --git a/src/smf/smfd/SmfCampaignThread.cc
>> b/src/smf/smfd/SmfCampaignThread.cc
>> index 413beb0..8f3d257 100644
>> --- a/src/smf/smfd/SmfCampaignThread.cc
>> +++ b/src/smf/smfd/SmfCampaignThread.cc
>> @@ -521,7 +521,7 @@ SaAisErrorT
>> SmfCampaignThread::createImmHandle(SmfCampaign *i_campaign) {
>> TRACE_ENTER();
>> SaAisErrorT rc = SA_AIS_OK;
>> int existCnt = 0;
>> -  SaVersionT immVersion = {'A', 2, 1};
>> +  SaVersionT immVersion = {'A', 2, 17};
>> SmfImmUtils immutil;
>> SaImmAttrValuesT_2 **attributes;
>> const char *campOiName = NULL;
>> diff --git a/src/smf/smfd/SmfExecControlHdl.h
>> b/src/smf/smfd/SmfExecControlHdl.h
>> index 3c3e8bc..8ba30a4 100644
>> --- a/src/smf/smfd/SmfExecControlHdl.h
>> +++ b/src/smf/smfd/SmfExecControlHdl.h
>> @@ -108,7 +108,7 @@ class SmfExecControlObjHandler {
>> SaImmAttrValuesT_2 *m_nodesForSingleStep_ad;
>>
>> // For storing IMM handles
>> -  const SaVersionT m_immVersion{'A', 2, 1};
>> +  const SaVersionT m_immVersion{'A', 2, 17};
>> SaImmHandleT m_omHandle;
>> SaImmAdminOwnerHandleT m_ownerHandle;
>> SaImmCcbHandleT m_ccbHandle;
>> diff --git a/src/smf/smfd/SmfImmApplierHdl.h
>> b/src/smf/smfd/SmfImmApplierHdl.h
>> index 68ffa1c..7bd037c 100644
>> --- a/src/smf/smfd/SmfImmApplierHdl.h
>> +++ b/src/smf/smfd/SmfImmApplierHdl.h
>> @@ -98,7 +98,7 @@ class SmfImmApplierHdl {
>> ExecuteImmCallbackReply ExecuteImmCallback(void);
>>
>>private:
>> -  const SaVersionT kImmVersion = {'A', 2, 11};
>> +  const SaVersionT kImmVersion = {'A', 2, 17};
>> static std::atomic instance_number_;
>> bool isCreated_;
>> std::string applier_name_;
>> diff --git a/src/smf/smfd/SmfImmOperation.cc
>> b/src/smf/smfd/SmfImmOperation.cc
>> index 1dd44df..445455f 100644
>> --- a/src/smf/smfd/SmfImmOperation.cc
>> +++ b/src/smf/smfd/SmfImmOperation.cc
>> @@ -414,8 +414,9 @@ SaAisErrorT
>> SmfImmCreateOperation::execute(SmfRollbackData *o_rollbackData) {
>> m_ccbHandle, (SaImmClassNameT)className, ,
>> (const SaImmAttrValuesT_2 **)m_immAttrValues);
>> if (result != SA_AIS_OK && result == SA_AIS_ERR_FAILED_OPERATION) {
>> -result = saImmOmCcbGetErrorStrings(m_ccbHandle, );
>> -if (errStrings) {
>> +SaAisErrorT result

Re: [devel] [PATCH 0/1] Review Request for imm: Add more details to no dangling CcbErrorString [#2433]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2017/04/21 12:14 PM, Hung Nguyen wrote:
> Summary: imm: Add more details to no dangling CcbErrorString [#2433]
> Review request for Ticket(s): 2433
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): develop
> Development branch: ticket-2433
> Base revision: bfebede5783121fc363f63536bbb89ba3355152e
> Personal repository: git://git.code.sf.net/u/xhunngu/review
>
> 
> 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
>
> NOTE: Patch(es) contain lines longer than 80 characers
>
> Comments (indicate scope for each "y" above):
> -
>
>
> revision 431b8569974cb2cca055feaa90e05a41fcbe3f42
> Author:   Hung Nguyen 
> Date: Fri, 21 Apr 2017 13:08:23 +0700
>
> imm: Add more details to no dangling CcbErrorString [#2433]
>
> Add more details to no dangling CcbErrorString.
>
>
>
> Complete diffstat:
> --
>   src/imm/immnd/ImmModel.cc | 50 
> +++
>   1 file changed, 50 insertions(+)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.gitconfig file (i.e. user.name, user.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

Re: [devel] [PATCH 0/1] Review Request for imm: Improve ccb error string handling [#2367]

[Neelakanta Reddy]

Hi Hieu,

Reviewed and tested the patch.
Ack.

/Neel.

On 2017/04/21 12:57 PM, Hieu Nguyen wrote:
> Summary: imm: Improve ccb error string handling [#2367]
> Review request for Ticket(s): 2367
> Peer Reviewer(s): *** Zoran Milinkovic, Neelakanta Reddy, Hung Nguyen / Hieu 
> Nguyen ***
> Pull request to: *** Hung Nguyen ***
> Affected branch(es): develop
> Development branch: ticket-2367
> Base revision: bfebede5783121fc363f63536bbb89ba3355152e
> Personal repository: git://git.code.sf.net/u/dhiengu/review
>
> 
> 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):
> -
>
>
> revision 4d4a99a72857515c71a5cc03314121f21f185e9a
> Author:   Hieu Nguyen <hieu.t.ngu...@dektech.com.au>
> Date: Fri, 21 Apr 2017 12:21:40 +0700
>
> imm: Improve ccb error string handling [#2367]
>
>
>
> Complete diffstat:
> --
>   src/imm/immnd/ImmModel.cc | 61 
> +++
>   1 file changed, 9 insertions(+), 52 deletions(-)
>
>
> Testing Commands:
> -
> See the ticket for more details.
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.gitconfig file (i.e. user.name, user.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/1] smf: updated the imm API vesrion to latest supported [#2431]

[Neelakanta Reddy]

---
 src/smf/smfd/SmfCampaignThread.cc  |  2 +-
 src/smf/smfd/SmfExecControlHdl.h   |  2 +-
 src/smf/smfd/SmfImmApplierHdl.h|  2 +-
 src/smf/smfd/SmfImmOperation.cc| 15 +--
 src/smf/smfd/SmfProcedureThread.cc |  2 +-
 src/smf/smfd/SmfUpgradeCampaign.cc |  2 ++
 src/smf/smfd/SmfUpgradeStep.h  |  2 +-
 src/smf/smfd/SmfUtils.cc   |  7 ---
 src/smf/smfd/smfd_campaign_oi.cc   |  2 +-
 src/smf/smfd/smfd_main.cc  |  2 +-
 10 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/src/smf/smfd/SmfCampaignThread.cc 
b/src/smf/smfd/SmfCampaignThread.cc
index 413beb0..8f3d257 100644
--- a/src/smf/smfd/SmfCampaignThread.cc
+++ b/src/smf/smfd/SmfCampaignThread.cc
@@ -521,7 +521,7 @@ SaAisErrorT SmfCampaignThread::createImmHandle(SmfCampaign 
*i_campaign) {
   TRACE_ENTER();
   SaAisErrorT rc = SA_AIS_OK;
   int existCnt = 0;
-  SaVersionT immVersion = {'A', 2, 1};
+  SaVersionT immVersion = {'A', 2, 17};
   SmfImmUtils immutil;
   SaImmAttrValuesT_2 **attributes;
   const char *campOiName = NULL;
diff --git a/src/smf/smfd/SmfExecControlHdl.h b/src/smf/smfd/SmfExecControlHdl.h
index 3c3e8bc..8ba30a4 100644
--- a/src/smf/smfd/SmfExecControlHdl.h
+++ b/src/smf/smfd/SmfExecControlHdl.h
@@ -108,7 +108,7 @@ class SmfExecControlObjHandler {
   SaImmAttrValuesT_2 *m_nodesForSingleStep_ad;
 
   // For storing IMM handles
-  const SaVersionT m_immVersion{'A', 2, 1};
+  const SaVersionT m_immVersion{'A', 2, 17};
   SaImmHandleT m_omHandle;
   SaImmAdminOwnerHandleT m_ownerHandle;
   SaImmCcbHandleT m_ccbHandle;
diff --git a/src/smf/smfd/SmfImmApplierHdl.h b/src/smf/smfd/SmfImmApplierHdl.h
index 68ffa1c..7bd037c 100644
--- a/src/smf/smfd/SmfImmApplierHdl.h
+++ b/src/smf/smfd/SmfImmApplierHdl.h
@@ -98,7 +98,7 @@ class SmfImmApplierHdl {
   ExecuteImmCallbackReply ExecuteImmCallback(void);
 
  private:
-  const SaVersionT kImmVersion = {'A', 2, 11};
+  const SaVersionT kImmVersion = {'A', 2, 17};
   static std::atomic instance_number_;
   bool isCreated_;
   std::string applier_name_;
diff --git a/src/smf/smfd/SmfImmOperation.cc b/src/smf/smfd/SmfImmOperation.cc
index 1dd44df..445455f 100644
--- a/src/smf/smfd/SmfImmOperation.cc
+++ b/src/smf/smfd/SmfImmOperation.cc
@@ -414,8 +414,9 @@ SaAisErrorT SmfImmCreateOperation::execute(SmfRollbackData 
*o_rollbackData) {
   m_ccbHandle, (SaImmClassNameT)className, ,
   (const SaImmAttrValuesT_2 **)m_immAttrValues);
   if (result != SA_AIS_OK && result == SA_AIS_ERR_FAILED_OPERATION) {
-result = saImmOmCcbGetErrorStrings(m_ccbHandle, );
-if (errStrings) {
+SaAisErrorT result1 = SA_AIS_OK;
+result1 = saImmOmCcbGetErrorStrings(m_ccbHandle, );
+if (result1 == SA_AIS_OK && errStrings) {
   TRACE("Received error string is %s", errStrings[0]);
   char *type = NULL;
   type = strstr(errStrings[0], "IMM: Resource abort: ");
@@ -651,8 +652,9 @@ SaAisErrorT SmfImmDeleteOperation::execute(SmfRollbackData 
*o_rollbackData) {
   const SaStringT *errStrings = NULL;
   result = immutil_saImmOmCcbObjectDelete(m_ccbHandle, );
   if (result != SA_AIS_OK && result == SA_AIS_ERR_FAILED_OPERATION) {
-result = saImmOmCcbGetErrorStrings(m_ccbHandle, );
-if (errStrings) {
+SaAisErrorT result1 = SA_AIS_OK;
+result1 = saImmOmCcbGetErrorStrings(m_ccbHandle, );
+if (result1 == SA_AIS_OK && errStrings) {
   TRACE("Received error string is %s", errStrings[0]);
   char *type = NULL;
   type = strstr(errStrings[0], "IMM: Resource abort: ");
@@ -1030,8 +1032,9 @@ SaAisErrorT 
SmfImmModifyOperation::execute(SmfRollbackData *o_rollbackData) {
   m_ccbHandle, ,
   (const SaImmAttrModificationT_2 **)m_immAttrMods);
   if (result != SA_AIS_OK && result == SA_AIS_ERR_FAILED_OPERATION) {
-result = saImmOmCcbGetErrorStrings(m_ccbHandle, );
-if (errStrings) {
+SaAisErrorT result1 = SA_AIS_OK;
+result1 = saImmOmCcbGetErrorStrings(m_ccbHandle, );
+if (result1 == SA_AIS_OK && errStrings) {
   TRACE("Received error string is %s", errStrings[0]);
   char *type = strstr(errStrings[0], "IMM: Resource abort: ");
   if (type != NULL) {
diff --git a/src/smf/smfd/SmfProcedureThread.cc 
b/src/smf/smfd/SmfProcedureThread.cc
index 269820b..023dc8e 100644
--- a/src/smf/smfd/SmfProcedureThread.cc
+++ b/src/smf/smfd/SmfProcedureThread.cc
@@ -179,7 +179,7 @@ SaAisErrorT SmfProcedureThread::createImmHandle(void) {
   TRACE_ENTER();
   SaAisErrorT rc = SA_AIS_OK;
   int existCnt = 0;
-  SaVersionT immVersion = {'A', 2, 1};
+  SaVersionT immVersion = {'A', 2, 17};
 
   // DN of the procedure
   const char *procName = m_procedure->getProcName().c_str();
diff --git a/src/smf/smfd/SmfUpgradeCampaign.cc 
b/src/smf/smfd/SmfUpgradeCampaign.cc
index 396bf10..aa03eba 100644
--- a/src/smf/smfd/SmfUpgradeCampaign.cc
+++ b/src/smf/smfd/SmfUpgradeCampaign.cc
@@ -1040,6 +1040,8 @@ void SmfUpgradeCampaign::resetMaintenanceState() {
* with Resource abort in error string.
*/
   

[devel] [PATCH 0/1] Review Request for smf: updated the imm API vesrion to latest supported [#2431]

[Neelakanta Reddy]

Summary: smf: updated the imm API vesrion to latest supported [#2431]
Review request for Ticket(s): 2431
Peer Reviewer(s): *** LIST THE TECH REVIEWER(S) / MAINTAINER(S) HERE ***
Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
Affected branch(es): develop, release, 5.2.x
Development branch: ticket-2431
Private repository: git://git.code.sf.net/u/neelakanta/review


Impacted area   Impact y/n

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


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

The IMM API version is changed across SMFD.
return value checks corrected for geterrorstrings.

revision a4c626d17618f69abffc35893294f26e3cde2887
Author: Neelakanta Reddy <reddy.neelaka...@oracle.com>
Date:   Thu, 20 Apr 2017 15:52:55 +0530

smf: updated the imm API vesrion to latest supported [#2431]



Complete diffstat:
--
 src/smf/smfd/SmfCampaignThread.cc  |  2 +-
 src/smf/smfd/SmfExecControlHdl.h   |  2 +-
 src/smf/smfd/SmfImmApplierHdl.h|  2 +-
 src/smf/smfd/SmfImmOperation.cc| 15 +--
 src/smf/smfd/SmfProcedureThread.cc |  2 +-
 src/smf/smfd/SmfUpgradeCampaign.cc |  2 ++
 src/smf/smfd/SmfUpgradeStep.h  |  2 +-
 src/smf/smfd/SmfUtils.cc   |  7 ---
 src/smf/smfd/smfd_campaign_oi.cc   |  2 +-
 src/smf/smfd/smfd_main.cc  |  2 +-
 10 files changed, 22 insertions(+), 16 deletions(-)


Testing Commands:
-
The IMM operations has to give ERR_BAD_OPERATION.
This can be reproduced by commiting the campaign and killing the IMMND of the 
payload.

Testing, Expected Results:
--
ccbgeterrorstring has to work correctly.

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 ~/.gitconfig file (i.e. user.name, user.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 li

Re: [devel] [PATCH 0 of 1] Review Request for imm: Use waitpid with WNOHANG to check for sync process and pbe process [#2420]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2017/04/11 05:38 PM, Hung Nguyen wrote:
> Summary: imm: Use waitpid with WNOHANG to check for sync process and pbe 
> process [#2420]
> Review request for Trac Ticket(s): 2420
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.1, 5.2, 5.3
> Development branch: 5.3
>
> 
> 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 65955917b1ceee59184013c4d9c2c510f81e8285
> Author:   Hung Nguyen 
> Date: Tue, 11 Apr 2017 19:05:48 +0700
>
>   imm: Use waitpid with WNOHANG to check for sync process and pbe process
>   [#2420]
>
>   Use waitpid with WNOHANG to check for sync process and pbe process. The
>   processes are checked before resending the intro message. The intro 
> message
>   is only sent when those processes exit.
>
>
> Complete diffstat:
> --
>   src/imm/immnd/immnd_evt.c  |   7 ++-
>   src/imm/immnd/immnd_proc.c |  25 +
>   2 files changed, 27 insertions(+), 5 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 1 of 1] imm: Check if response is NULL when sending MDS sync message [#2401]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2017/04/04 12:40 PM, Hung Nguyen wrote:
>   src/imm/agent/imma_mds.cc |  6 +-
>   1 files changed, 5 insertions(+), 1 deletions(-)
>
>
> Check if response is NULL when sending MDS sync message.
>
> diff --git a/src/imm/agent/imma_mds.cc b/src/imm/agent/imma_mds.cc
> --- a/src/imm/agent/imma_mds.cc
> +++ b/src/imm/agent/imma_mds.cc
> @@ -602,8 +602,12 @@ uint32_t imma_mds_msg_sync_send(uint32_t
>   /* send the message */
>   rc = ncsmds_api(_info);
>   
> - if (rc == NCSCC_RC_SUCCESS)
> + if (rc == NCSCC_RC_SUCCESS) {
>   *o_evt = (IMMSV_EVT *) mds_info.info.svc_send.info.sndrsp.o_rsp;
> + if (*o_evt == NULL) {
> + rc = NCSCC_RC_FAILURE;
> + }
> + }
>   
>   return rc;
>   }


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

Re: [devel] [PATCH 1 of 1] smfd: fix race condition when detecting async failures [#2413]

[Neelakanta Reddy]

Hi Alex,

got it.
Ack from me.

Thanks,
Neel.

On 2017/04/08 03:25 AM, Alex Jones wrote:
>
> Hi Neel,
>
>   Replies to your comments:
>
> (1)I don’t see this. With this patch can you get the system into a 
> state where the suMaintenanceCampaign is set in AMF, the component 
> crashes right before the SMF commit clears the suMaintenanceCampaign, 
> and thecmgnError is not set? If so, that’s a bug that we should 
> address. The SMF-AIS spec states that the suMaintenanceCampaign 
> attribute is cleared when the campaign is committed. Therefore it is 
> entirely possible that an SU could become disabled right before the 
> attribute is cleared, and the campaign still transitions to COMMITTED. 
> But, cmpnError should still be set in this case. So, as I read the 
> spec the operator needs to check this after committing, and may need 
> to repair an SU after committing a campaign, if this corner case occurs.
>
> (2)Well, the SMF-AIS spec says that asyncFailures are considered in 
> EVERY state while the suMaintenanceCampaign attribute is set. A 
> suspend is only done in the states you mention, but cmpnError should 
> be set in all states. This is already handled by the campaign state 
> machine. Look at SmfCampState.cc. The ::asyncFailure virtual function 
> only suspends the campaign in the states that you mention. If an 
> asyncFailure occurs in any other state, the base class virtual 
> function is called which does nothing.
>
> Alex
>
> *From:*Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
> *Sent:* Friday, April 7, 2017 5:05 AM
> *To:* Alex Jones <alex.jo...@genband.com>; lennart.l...@ericsson.com; 
> rafael.odza...@ericsson.com
> *Cc:* opensaf-devel@lists.sourceforge.net
> *Subject:* Re: [PATCH 1 of 1] smfd: fix race condition when detecting 
> async failures [#2413]
>
> 
>
> NOTICE: This email was received from an EXTERNAL sender
>
> 
>
>
> Hi Alex,
>
> Reviewed and tested the patch.
> The patch avoids, the crash in smfd.
>
> I have the following Questions on the implementation(which was
> overlooked at the time of #2145 review):
>
> 1. If the component is killed when the campaign is in
> SA_SMF_CMPG_EXECUTION_COMPLETED state(as in the defect) and
> the amfnd does not re-start the component because,
> saAmfSUMaintenanceCampaign is set. The saSmfCmpgError indication is not
> given in SMF, because the campaign is in the process of committing.
>
> who does this justify Asynchronous Failures of AMF Entities?
>
> 2.
> according to SMF AIS, the async failures has to be considered Executing,
> Suspending, or RollingBack only.
> Then how do we prevent in other states? And the AMFND still will not
> re-start(correct) because of saAmfSUMaintenanceCampaign is set.
>
> Thanks,
> Neel.
>
> On 2017/04/06 11:56 PM, Alex Jones wrote:
> > src/smf/smfd/SmfCampaignThread.cc | 16 ++--
> > 1 files changed, 10 insertions(+), 6 deletions(-)
> >
> >
> > smfd core dumps during commit of campaign.
> >
> > If an AMF SU under maintenance fails right as the campaign commit is 
> done, there
> > is a race condition present. Before SMF clears the suMaintenaceCampaign
> > attribute of the SU, if the SU fails, it will send a notification. 
> Meanwhile,
> > the commit deletes upgrade campaign pointer inside smfd. If the 
> deletion of the
> > campaign pointer inside smfd occurs before it receives the NTF event 
> a crash
> > will occur because the campaign pointer is gone.
> >
> > Solution is to always process NTF events before processing the 
> termination of
> > the campaign. The campaign termination code sets "m_running" to 
> false, and
> > deletes the pointer. This should always be last in the poll loop so 
> that the
> > loop will exit immediately without processing any NTF events (or 
> other future
> > events.)
> >
> > diff --git a/src/smf/smfd/SmfCampaignThread.cc 
> b/src/smf/smfd/SmfCampaignThread.cc
> > --- a/src/smf/smfd/SmfCampaignThread.cc
> > +++ b/src/smf/smfd/SmfCampaignThread.cc
> > @@ -907,12 +907,10 @@ int SmfCampaignThread::handleEvents(void
> > break;
> > }
> >
> > - /* Process the Mail box events */
> > - if (fds[0].revents & POLLIN) {
> > - /* dispatch MBX events */
> > - processEvt();
> > - }
> > -
> > + /*
> > + * Handle NTF events first because processEvt may delete and 
> terminate the
> > + * campaign thread.
> > + */
> > if (fds[1].revents & POLLIN) {
> > // d

Re: [devel] [PATCH 1 of 1] smfd: fix race condition when detecting async failures [#2413]

[Neelakanta Reddy]

Hi Alex,

Reviewed and tested the patch.
The patch avoids, the crash in smfd.

I have the following Questions on the implementation(which was 
overlooked at the time of #2145 review):

1. If the component is killed when the campaign is in 
SA_SMF_CMPG_EXECUTION_COMPLETED state(as in the defect) and
the amfnd does not re-start the component because, 
saAmfSUMaintenanceCampaign  is set. The saSmfCmpgError indication is not
given in SMF, because the campaign is  in the process of committing.

who does this justify Asynchronous Failures of AMF Entities?

2.
according to SMF AIS, the async failures has to be considered Executing, 
Suspending, or RollingBack only.
Then how do we prevent in other states? And the AMFND still will not 
re-start(correct) because of saAmfSUMaintenanceCampaign  is set.

Thanks,
Neel.

On 2017/04/06 11:56 PM, Alex Jones wrote:
>   src/smf/smfd/SmfCampaignThread.cc |  16 ++--
>   1 files changed, 10 insertions(+), 6 deletions(-)
>
>
> smfd core dumps during commit of campaign.
>
> If an AMF SU under maintenance fails right as the campaign commit is done, 
> there
> is a race condition present. Before SMF clears the suMaintenaceCampaign
> attribute of the SU, if the SU fails, it will send a notification. Meanwhile,
> the commit deletes upgrade campaign pointer inside smfd. If the deletion of 
> the
> campaign pointer inside smfd occurs before it receives the NTF event a crash
> will occur because the campaign pointer is gone.
>
> Solution is to always process NTF events before processing the termination of
> the campaign. The campaign termination code sets "m_running" to false, and
> deletes the pointer. This should always be last in the poll loop so that the
> loop will exit immediately without processing any NTF events (or other future
> events.)
>
> diff --git a/src/smf/smfd/SmfCampaignThread.cc 
> b/src/smf/smfd/SmfCampaignThread.cc
> --- a/src/smf/smfd/SmfCampaignThread.cc
> +++ b/src/smf/smfd/SmfCampaignThread.cc
> @@ -907,12 +907,10 @@ int SmfCampaignThread::handleEvents(void
>   break;
>   }
>   
> -/* Process the Mail box events */
> - if (fds[0].revents & POLLIN) {
> - /* dispatch MBX events */
> - processEvt();
> - }
> -
> +/*
> + * Handle NTF events first because processEvt may delete and terminate 
> the
> + * campaign thread.
> + */
>   if (fds[1].revents & POLLIN) {
>   // dispatch NTF events
>   rc = saNtfDispatch(m_ntfHandle, SA_DISPATCH_ALL);
> @@ -922,6 +920,12 @@ int SmfCampaignThread::handleEvents(void
>   }
>   }
>   
> +/* Process the Mail box events */
> + if (fds[0].revents & POLLIN) {
> + /* dispatch MBX events */
> + processEvt();
> + }
> +
>   m_campaign->updateElapsedTime();
>   }
>   TRACE_LEAVE();
>


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

Re: [devel] [PATCH 0 of 1] Review Request for immm: Fixed memory leak in imm_cfg.c file [#2408]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2017/04/03 10:55 AM, Hieu Nguyen wrote:
> Summary: immm: Fixed memory leak in imm_cfg.c file [#2408]
> Review request for Trac Ticket(s): 2408
> Peer Reviewer(s): Zoran, Neel, Hung
> Pull request to: Hung
> Affected branch(es): 5.0, 5.1, 5.2, 5.3
> Development branch: 5.3
>
> 
> 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 ccef2796fd77574ac4e6c1970917c08c4a31c689
> Author:   Hieu Nguyen 
> Date: Mon, 03 Apr 2017 11:45:38 +0700
>
>   immm: Fixed memory leak in imm_cfg.c file [#2408]
>
>   Fixed memory leak in unique_admiOwner() function of imm_cfg.c file
>
>
> Complete diffstat:
> --
>   src/imm/tools/imm_cfg.c |  10 +++---
>   1 files changed, 7 insertions(+), 3 deletions(-)
>
>
> Testing Commands:
> -
> Run cppcheck tool on imm service
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


--
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] Latest staging is failing with gcc 6.1

[Neelakanta Reddy]

Hi

Failing in gcc 6.1(passed in gcc 4.9):

   CXXsrc/base/lib_libopensaf_core_la-hash.lo
src/base/hash.cc:97:1: error: '{anonymous}::HashLibrary::~HashLibrary()' 
defined but not used [-Werror=unused-function]
  HashLibrary::~HashLibrary() {
  ^~~
cc1plus: all warnings being treated as errors
make[2]: *** [src/base/lib_libopensaf_core_la-hash.lo] Error 1
make[2]: Leaving directory `/home/neel/testing/smf/staging_2342'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/neel/testing/smf/staging_2342'
make: *** [all] Error 2


When moved into the class definition, the error was not observed.


Thanks,
Neel.

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

Re: [devel] [PATCH 1 of 1] imm :decrement the pending reply when error is other than SA_AIS_OK when newCcbId is called [#2386]

[Neelakanta Reddy]

Hi zoran,

Yes, will Re-publish the patch.

Thanks,
Neel.

On 2017/03/20 05:57 PM, Zoran Milinkovic wrote:
> Hi Neelakanta,
>
> cl_node is always NULL when imma_proc_decrement_pending_reply() is called.
> It may crash IMM client in imma_proc_decrement_pending_reply() function.
>
> Thanks,
> Zoran
>
> -Original Message-
> From: reddy.neelaka...@oracle.com [mailto:reddy.neelaka...@oracle.com]
> Sent: den 17 mars 2017 10:29
> To: Zoran Milinkovic ; Hung Duc Nguyen 
> 
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] imm :decrement the pending reply when error is other 
> than SA_AIS_OK when newCcbId is called [#2386]
>
>   src/imm/agent/imma_om_api.cc |  25 -
>   1 files changed, 20 insertions(+), 5 deletions(-)
>
>
> diff --git a/src/imm/agent/imma_om_api.cc b/src/imm/agent/imma_om_api.cc
> --- a/src/imm/agent/imma_om_api.cc
> +++ b/src/imm/agent/imma_om_api.cc
> @@ -1817,7 +1817,10 @@ static SaAisErrorT ccb_object_create_com
>   }
>   rc = imma_newCcbId(cb, ccb_node, adminOwnerId, , 
> cl_node->syncr_timeout);
>   cl_node = NULL;
> - if(rc == SA_AIS_ERR_LIBRARY) {goto done;}
> + if(rc == SA_AIS_ERR_LIBRARY) {
> + imma_proc_decrement_pending_reply(cl_node, true);
> + goto done;
> + }
>   /* ccb_node still valid if rc == SA_AIS_OK. */
>   if(rc == SA_AIS_OK) {
>   osafassert(!(ccb_node->mExclusive));
> @@ -2412,7 +2415,10 @@ static SaAisErrorT ccb_object_modify_com
>   }
>   rc = imma_newCcbId(cb, ccb_node, adminOwnerId, , 
> cl_node->syncr_timeout);
>   cl_node = NULL;
> - if(rc == SA_AIS_ERR_LIBRARY) {goto done;}
> + if(rc == SA_AIS_ERR_LIBRARY) {
> + imma_proc_decrement_pending_reply(cl_node, true);
> + goto done;
> + }
>   /* ccb_node still valid if rc == SA_AIS_OK. */
>   if(rc == SA_AIS_OK) {
>   osafassert(!(ccb_node->mExclusive));
> @@ -2895,7 +2901,10 @@ static SaAisErrorT ccb_object_delete_com
>   }
>   rc = imma_newCcbId(cb, ccb_node, adminOwnerId, , 
> cl_node->syncr_timeout);
>   cl_node = NULL;
> - if(rc == SA_AIS_ERR_LIBRARY) {goto done;}
> + if(rc == SA_AIS_ERR_LIBRARY) {
> + imma_proc_decrement_pending_reply(cl_node, true);
> + goto done;
> + }
>   /* ccb_node still valid if rc == SA_AIS_OK. */
>   if(rc == SA_AIS_OK) {
>   osafassert(!(ccb_node->mExclusive));
> @@ -6521,7 +6530,10 @@ SaAisErrorT saImmOmCcbObjectRead(SaImmCc
>   }
>   rc = imma_newCcbId(cb, ccb_node, adminOwnerId, , 
> cl_node->syncr_timeout);
>   cl_node = NULL;
> - if(rc == SA_AIS_ERR_LIBRARY) {goto done;}
> + if(rc == SA_AIS_ERR_LIBRARY) {
> + imma_proc_decrement_pending_reply(cl_node, true);
> + goto done;
> + }
>   /* ccb_node still valid if rc == SA_AIS_OK. */
>   if(rc == SA_AIS_OK) {
>   osafassert(!(ccb_node->mExclusive));
> @@ -9191,7 +9203,10 @@ static SaAisErrorT imma_finalizeCcb(SaIm
>   
>   rc = imma_newCcbId(cb, ccb_node, adminOwnerId, , 
> cl_node->syncr_timeout);
>   cl_node=NULL;
> - if(rc != SA_AIS_OK) {goto done;}
> + if(rc != SA_AIS_OK) {
> + imma_proc_decrement_pending_reply(cl_node, 
> true);
> + goto done;
> + }
>   /* ccb_node still valid if rc == SA_AIS_OK. */
>   if(rc == SA_AIS_OK) {
>   osafassert(!(ccb_node->mExclusive));


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

Re: [devel] [PATCH 0 of 1] Review Request for smfd: fix campaign suspend when last step of procedure is executing [#2332]

[Neelakanta Reddy]

Hi Alex,

Reviewed and tested the patch.
Ack.

/Neel.

On 2017/03/08 02:51 AM, Alex Jones wrote:
> Summary: smfd: fix campaign suspend when last step of procedure is executing
> Review request for Trac Ticket(s): 2332
> Peer Reviewer(s): Neel, Lennart, Rafael
> Pull request to:
> Affected branch(es): default, 5.1, 5.0
> Development branch: <>
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
> There is a comment being removed which explains why this shouldn't be done,
> but I don't understand why.
>
> changeset 7bc8dd36c9b2760a15bb0cd08a57b8fff8a26e87
> Author:   Alex Jones 
> Date: Tue, 07 Mar 2017 16:05:07 -0500
>
>   smfd: fix campaign suspend when last step of procedure is executing 
> [#2332]
>
>   Campaign is in suspended state (after ADMIN_SUSPEND sent to it), but no
>   procedure is in suspended state.
>
>   The code in SmfProcStateExecuting::executeStep and
>   SmfProcStateRollingBack::rollbackStep does not properly handle the last
>   step. If the last step completes the EXECUTE message is not sent back 
> to the
>   procedure thread to see if a pending suspend is sitting there, but 
> continues
>   on with the wrapup and returns COMPLETED. Then the waiting SUSPEND 
> message
>   is executed, but the procedure is in COMPLETED state, so it is ignored.
>
>   Solution is to remove the code which checks if this is the last step.
>
>
> Complete diffstat:
> --
>   src/smf/smfd/SmfProcState.cc |  48 
> ++--
>   1 files changed, 14 insertions(+), 34 deletions(-)
>
>
> Testing Commands:
> -
> (1) run the campaign_rolling_nodes_os_installremove.xml campaign in the 
> samples directory
> (2) after the second node has rebooted, do "smf-adm suspend "
> (3) verify that the campaign has successfully suspended
>
>
> Testing, Expected Results:
> --
> (1) "smf-state proc all" will show no procedure in suspended state
> (2) "smf-adm execute " will fail
>
>
> 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 

Re: [devel] [PATCH 1 of 1] imm: Fix all Cppcheck 1.77 issues [#2333]

[Neelakanta Reddy]

Hi Mahesh,

Reviewed and tested the patch.
Ack.

/Neel.

On 2017/03/03 11:12 AM, mahesh.va...@oracle.com wrote:
>   src/imm/agent/imma_db.cc |   8 +---
>   src/imm/agent/imma_mds.cc|   6 +--
>   src/imm/agent/imma_oi_api.cc |   3 +-
>   src/imm/agent/imma_om_api.cc |  19 +
>   src/imm/agent/imma_proc.cc   |  12 ++
>   src/imm/immd/immd_db.c   |   9 +---
>   src/imm/immd/immd_evt.c  |  29 ++-
>   src/imm/immd/immd_mbcsv.c|   9 +---
>   src/imm/immd/immd_mds.c  |  17 ++--
>   src/imm/immnd/ImmModel.cc|  80 
> ---
>   src/imm/immnd/immnd_clm.c|   4 +-
>   src/imm/immnd/immnd_db.c |   7 +--
>   src/imm/immnd/immnd_evt.c|  29 +--
>   src/imm/immnd/immnd_main.c   |   4 +-
>   src/imm/immnd/immnd_mds.c|  10 +---
>   src/imm/immnd/immnd_proc.c   |   7 +--
>   16 files changed, 98 insertions(+), 155 deletions(-)
>
>
> Except never used functions all other issues are fixed  of below,
> some UN-pushed enhancement may be using those functions.
>
> [staging/src/imm/immnd/ImmModel.cc:2985] -> 
> [staging/src/imm/immnd/ImmModel.cc:3002]: (warning) Either the condition 
> 'increment&' is redundant or there is possible null pointer 
> dereference: immObject.
> [staging/src/imm/immnd/ImmModel.cc:2986] -> 
> [staging/src/imm/immnd/ImmModel.cc:3002]: (warning) Either the condition 
> 'increment&' is redundant or there is possible null pointer 
> dereference: immObject.
> [staging/src/imm/immnd/ImmModel.cc:10798]: (style) C-style pointer casting
> [staging/src/imm/immnd/ImmModel.cc:11027]: (style) C-style pointer casting
> [staging/src/imm/immnd/ImmModel.cc:12510]: (style) C-style pointer casting
> [staging/src/imm/immnd/ImmModel.cc:13921]: (style) C-style pointer casting
> [staging/src/imm/immnd/ImmModel.cc:2980] -> 
> [staging/src/imm/immnd/ImmModel.cc:2984]: (style) Variable 'immObject' is 
> reassigned a value before the old one has been used.
> [staging/src/imm/immnd/ImmModel.cc:7141] -> 
> [staging/src/imm/immnd/ImmModel.cc:7154]: (style) Variable 'current' is 
> reassigned a value before the old one has been used.
> [staging/src/imm/immnd/ImmModel.cc:7445] -> 
> [staging/src/imm/immnd/ImmModel.cc:7455]: (style) Variable 'ccb' is 
> reassigned a value before the old one has been used.
> [staging/src/imm/immnd/ImmModel.cc:7448] -> 
> [staging/src/imm/immnd/ImmModel.cc:7460]: (style) Variable 'oMut' is 
> reassigned a value before the old one has been used.
> [staging/src/imm/immnd/ImmModel.cc:7541] -> 
> [staging/src/imm/immnd/ImmModel.cc:7550]: (style) Variable 'afim' is 
> reassigned a value before the old one has been used.
> [staging/src/imm/immnd/ImmModel.cc:7579] -> 
> [staging/src/imm/immnd/ImmModel.cc:7589]: (style) Variable 'afim' is 
> reassigned a value before the old one has been used.
> [staging/src/imm/immnd/ImmModel.cc:14144] -> 
> [staging/src/imm/immnd/ImmModel.cc:14148]: (style) Variable 'immObject' is 
> reassigned a value before the old one has been used.
> [staging/src/imm/immnd/ImmModel.cc:673]: (style) The scope of the variable 
> 'ix' can be reduced.
> [staging/src/imm/immnd/ImmModel.cc:905]: (style) The scope of the variable 
> 'ix' can be reduced.
> [staging/src/imm/immnd/ImmModel.cc:931]: (style) The scope of the variable 
> 'ix' can be reduced.
> [staging/src/imm/immnd/ImmModel.cc:1041]: (style) The scope of the variable 
> 'ix' can be reduced.
> [staging/src/imm/immnd/ImmModel.cc:1074]: (style) The scope of the variable 
> 'ix' can be reduced.
> [staging/src/imm/immnd/ImmModel.cc:1882]: (style) The scope of the variable 
> 'ix' can be reduced.
> [staging/src/imm/immnd/ImmModel.cc:2031]: (style) The scope of the variable 
> 'ix' can be reduced.
> [staging/src/imm/immnd/ImmModel.cc:5462]: (style) The scope of the variable 
> 'ai' can be reduced.
> [staging/src/imm/immnd/ImmModel.cc:16545]: (style) The scope of the variable 
> 'sendCompletedToSlave' can be reduced.
> [staging/src/imm/immnd/ImmModel.cc:19363]: (style) Unused variable: i3
> [staging/src/imm/immnd/ImmModel.cc:104]: (style) Struct 
> 'ImplementerCcbAssociation' has a constructor with 1 argument that is not 
> explicit.
> [staging/src/imm/immnd/ImmModel.cc:118]: (style) Struct 'ClassInfo' has a 
> constructor with 1 argument that is not explicit.
> [staging/src/imm/immnd/ImmModel.cc:269]: (style) Struct 'ObjectMutation' has 
> a constructor with 1 argument that is not explicit.
> [staging/src/imm/immnd/ImmModel.cc:576]: (style) Struct 'AttrFlagIncludes' 
> has a constructor with 1 argument that is not explicit.
> [staging/src/imm/immnd/ImmModel.cc:587]: (style) Struct 'IdIs' has a 
> constructor with 1 argument that is not explicit.
> [staging/src/imm/immnd/ImmModel.cc:598]: (style) Struct 'CcbIdIs' has a 
> constructor with 1 argument that is not explicit.
> [staging/src/imm/immnd/ImmModel.cc:4862]: (style) Struct 'AttrDescriptionGet' 
> has a constructor with 1 argument that is not explicit.
> 

Re: [devel] [PATCH 1 of 1] imm: fix log level for saClmDispatch [#2353]

[Neelakanta Reddy]

Hi Zoran,

Reviewed the patch.
Ack.

/Neel.

On 2017/03/07 09:34 PM, Zoran Milinkovic wrote:
>   src/imm/immnd/immnd_main.c |  3 ++-
>   1 files changed, 2 insertions(+), 1 deletions(-)
>
>
> If saClmDispatch fails with SA_AIS_ERR_BAD_HANDLE error, the message will be 
> logged with warning level and CLM handle will be reinitialized.
> All other saClmDispatch errors will be logged with error level.
>
> diff --git a/src/imm/immnd/immnd_main.c b/src/imm/immnd/immnd_main.c
> --- a/src/imm/immnd/immnd_main.c
> +++ b/src/imm/immnd/immnd_main.c
> @@ -407,14 +407,15 @@ int main(int argc, char *argv[])
>   
>   if (fds[FD_CLM].revents & POLLIN) {
>   if ((error = saClmDispatch(immnd_cb->clm_hdl, 
> SA_DISPATCH_ALL)) != SA_AIS_OK) {
> - LOG_ER("saClmDispatch failed: %u", 
> error);
>   if(error == SA_AIS_ERR_BAD_HANDLE){
> + LOG_WA("saClmDispatch failed: 
> %u", error);
>   LOG_NO("Re-initializing with 
> CLMS");
>   
> saClmFinalize(immnd_cb->clm_hdl);
>   
> immnd_clm_node_cleanup(immnd_cb);
>   immnd_cb->clmSelectionObject = 
> -1;
>   immnd_init_with_clm();
>   } else {
> + LOG_ER("saClmDispatch failed: 
> %u", error);
>   break;
>   }
>   }


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

Re: [devel] SMF: problem with suspend

[Neelakanta Reddy]

Hi Alex,

send, the review request
we will test the patch.

Thanks,
Neel.

On 2017/03/06 08:24 PM, Alex Jones wrote:
> Hi Neel,
>
>I see this problem without my changes (2144 and 2145). If I do
> "smf-adm suspend ", and the currently executing procedure has one
> step left waiting for reboot, when the step completes, the procedure
> will not move to "suspended" state.
>
>When I remove this code in the patch, everything works fine. It's not
> clear to me why we can't remove it.
>
> Alex
>
> On 03/06/2017 03:05 AM, Neelakanta Reddy wrote:
>> 
>> NOTICE: This email was received from an EXTERNAL sender
>> 
>>
>> Hi Alex,
>>
>> What problem has been observed, you mean say the campaign suspend is not
>> happening after #2145 and #2144 when the component restart is found at
>> the time of last step?
>>
>> Thanks,
>> Neel.
>>
>> On 2017/03/03 11:58 PM, Alex Jones wrote:
>>> Hi Guys,
>>>
>>> I've created ticket 2332 for a problem that I'm seeing. I'd like to
>>> remove some code in SmfProcState.cc, but there's a comment there that I
>>> don't understand.
>>>
>>> Can any of you explain the comments about "We don't want to be able to
>>> suspend between ..."? I can't figure out why we can't do this.
>>>
>>> I've attached the proposed diff.
>>>
>>> Alex


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

Re: [devel] [PATCH 1 of 1] imm:changing clm indicating object to CLMS node up [#2330] V2

[Neelakanta Reddy]

Hi Zoran,

You are using older version of the patch, please use V2(the problem has 
been resolved).

The following is the syslog message, when same test is performed:

Apr  3 16:15:19 PL4 osafimmnd[17434]: NO Re-introduce-me 
highestProcessed:1109 highestReceived:1109
Apr  3 16:15:19 PL4 osafimmnd[17434]: WA MDS Send Failed to service:IMMD 
rc:2
Apr  3 16:15:20 PL4 osafimmnd[17434]: NO Re-introduce-me 
highestProcessed:1109 highestReceived:1109
Apr  3 16:15:20 PL4 osafimmnd[17434]: WA MDS Send Failed to service:IMMD 
rc:2
Apr  3 16:15:21 PL4 osafimmnd[17434]: NO IMMD service is UP ... 
ScAbsenseAllowed?:900 introduced?:2
Apr  3 16:15:21 PL4 osafimmnd[17434]: NO Re-introduce-me 
highestProcessed:1109 highestReceived:1109
Apr  3 16:15:21 PL4 osafimmnd[17434]: NO This IMMND is now the NEW Coord
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Announce sync, epoch:3
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO SERVER STATE: IMM_SERVER_READY 
--> IMM_SERVER_SYNC_SERVER
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO NODE STATE-> IMM_NODE_R_AVAILABLE
Apr  3 16:15:22 PL4 osafimmloadd: NO Sync starting
Apr  3 16:15:22 PL4 osafimmloadd: IN Synced 382 objects in total
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO NODE STATE-> 
IMM_NODE_FULLY_AVAILABLE 18511
Apr  3 16:15:22 PL4 osafimmloadd: NO Sync ending normally
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Epoch set to 3 in ImmModel
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Implementer connected: 14 
(MsgQueueService132111) <51, 2040f>
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Implementer connected: 15 
(safLogService) <0, 2010f>
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Implementer (applier) 
connected: 16 (@safLogService_appl) <0, 2010f>
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO SERVER STATE: 
IMM_SERVER_SYNC_SERVER --> IMM_SERVER_READY
Apr  3 16:15:22 PL4 osafmsgnd[17466]: ER saClmDispatch Failed with error 9
Apr  3 16:15:22 PL4 osafckptnd[17495]: NO Bad CLM handle. Reinitializing.
Apr  3 16:15:22 PL4 osafclmna[17424]: NO 
safNode=PL-4,safCluster=myClmCluster Joined cluster, nodeid=2040f
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO AVD NEW_ACTIVE, adest:1
Apr  3 16:15:22 PL4 osafimmnd[17434]: ER saClmDispatch failed: 9
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Re-initializing with CLMS
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Implementer connected: 17 
(safClmService) <0, 2010f>
Apr  3 16:15:22 PL4 osafimmnd[17434]: NO Implementer connected: 18 
(safAmfService) <0, 2010f>
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO saClmDispatch BAD_HANDLE
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO 1 SISU states sent
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO 1 SU states sent
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO 7 CSICOMP states sent
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO 7 COMP states sent
Apr  3 16:15:22 PL4 osafamfnd[17444]: NO Sending node up due to 
NCSMDS_NEW_ACTIVE
Apr  3 16:15:24 PL4 osafckptnd[17495]: NO CLM selection object was 
updated. (15)
Apr  3 16:15:34 PL4 osafimmnd[17434]: NO Implementer connected: 19 
(MsgQueueService131343) <0, 2010f>
Apr  3 16:15:34 PL4 osafimmnd[17434]: NO Implementer connected: 20 
(safMsgGrpService) <0, 2010f>
Apr  3 16:15:34 PL4 osafimmnd[17434]: NO Implementer connected: 21 
(safEvtService) <0, 2010f>
Apr  3 16:15:34 PL4 osafimmnd[17434]: NO Implementer connected: 22 
(safLckService) <0, 2010f>
Apr  3 16:15:34 PL4 osafimmnd[17434]: NO Implementer connected: 23 
(safSmfService) <0, 2010f>
Apr  3 16:15:34 PL4 osafimmnd[17434]: NO Implementer (applier) 
connected: 24 (@safSmf_applier1) <0, 2010f

Thanks,
Neel.

On 2017/03/06 08:17 PM, Zoran Milinkovic wrote:
> Hi Neelakanta,
>
> After applying the patch, immnd on payloads crashing after coming from 
> headless state.
> Before the patch, immnd was more stable.
>
> This is a test with one SC and one PL with SC absence allowed.
> 1. Bring both SC-1 and PL-3 up
> 2. Take SC-1 down to go to headless state
> 3. Take SC-1 up, and after the sync, PL-3 reboots
>
> These are logs from PL-3 when the sync was announced:
>
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Announce sync, epoch:45
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO SERVER STATE: IMM_SERVER_READY --> 
> IMM_SERVER_SYNC_SERVER
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO NODE STATE-> IMM_NODE_R_AVAILABLE
> Mar  6 15:37:08 PL-3 osafimmloadd: NO Sync starting
> Mar  6 15:37:08 PL-3 osafimmloadd: IN Synced 382 objects in total
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO NODE STATE-> 
> IMM_NODE_FULLY_AVAILABLE 18511
> Mar  6 15:37:08 PL-3 osafimmloadd: NO Sync ending normally
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Epoch set to 45 in ImmModel
> Mar  6 15:37:08 PL-3 osafimmpbed: NO Update epoch 45 committing with 
> ccbId:1000d/4294967309
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Implementer connected: 37 
> (MsgQueueService131855) <53, 2030f>
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Implementer connected: 38 
> (safLogService) <0, 2010f>
> Mar  6 15:37:08 PL-3 osafimmnd[2609]: NO Implementer (applier) connected: 39 
> (@safLogService_appl) <0, 2010f>
> Mar  6 15:37:08 

Re: [devel] [PATCH 0 of 1] Review Request for imm: Sync latest ccb-id to sync clients [#2323]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2017/03/01 12:32 PM, Hung Nguyen wrote:
> Summary: imm: Sync latest ccb-id to sync clients [#2323]
> Review request for Trac Ticket(s): 2323
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.0, 5.1, 5.2
> Development branch: 5.2
>
> 
> 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 bb9bc2cb99f8fa18ee3ee74094468c0bbef15ead
> Author:   Hung Nguyen 
> Date: Wed, 01 Mar 2017 14:01:14 +0700
>
>   imm: Sync latest ccb-id to sync clients [#2323]
>
>   When finalizing sync, immnd coordinator stores latest ccb-id in
>   ImmsvCcbOutcomeList. It is stored as a ccb with ccb-id being zero. The 
> sync
>   clients update mLatestCcbId when receiving ND2ND_SYNC_FINALIZE_2 
> message.
>
>   When rolling upgrading, it's not a valid case when an old-versioned node
>   joins the cluster. After rebooting, the nodes are supposed to be 
> upgraded
>   and run with new version. We don't have to worry about old-versioned 
> sync-
>   client receiving ccb-id = 0.
>
>   We don't have to sync latest admo-id and latest implementer-id because 
> amdo
>   and implementer are all "cleared" in IMMND when headless. There won't 
> be any
>   problem if IMMD reset IMMD_CB.admo_id_count and IMMD_CB.impl_count.
>
>
> Complete diffstat:
> --
>   src/imm/immnd/ImmModel.cc |  23 +++
>   src/imm/immnd/ImmModel.h  |   2 +-
>   2 files changed, 20 insertions(+), 5 deletions(-)
>
>
> Testing Commands:
> -
> See the ticket for more details.
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch 

Re: [devel] SMF: problem with suspend

[Neelakanta Reddy]

Hi Alex,

What problem has been observed, you mean say the campaign suspend is not 
happening after #2145 and #2144 when the component restart is found at 
the time of last step?

Thanks,
Neel.

On 2017/03/03 11:58 PM, Alex Jones wrote:
> Hi Guys,
>
>I've created ticket 2332 for a problem that I'm seeing. I'd like to
> remove some code in SmfProcState.cc, but there's a comment there that I
> don't understand.
>
>Can any of you explain the comments about "We don't want to be able to
> suspend between ..."? I can't figure out why we can't do this.
>
>I've attached the proposed diff.
>
> Alex


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

Re: [devel] [PATCH 1 of 1] smfd: add support for asynchronous detection of failed AMF entities [#2145]

[Neelakanta Reddy]

Hi Alex,

Reviewed and tested the patch.
Ack.

/Neel.

On 2017/03/01 07:49 AM, Alex Jones wrote:
>   src/smf/smfd/SmfCampState.cc   |   68 ++
>   src/smf/smfd/SmfCampState.h|7 +
>   src/smf/smfd/SmfCampaignThread.cc  |  233 
> -
>   src/smf/smfd/SmfCampaignThread.h   |   15 ++
>   src/smf/smfd/SmfStepTypes.cc   |   32 ++--
>   src/smf/smfd/SmfUpgradeCampaign.cc |   20 +++
>   src/smf/smfd/SmfUpgradeCampaign.h  |7 +
>   7 files changed, 363 insertions(+), 19 deletions(-)
>
>
> This patch adds support for section 4.2.1.3 of SMF A.01.02 spec.
>
> diff --git a/src/smf/smfd/SmfCampState.cc b/src/smf/smfd/SmfCampState.cc
> --- a/src/smf/smfd/SmfCampState.cc
> +++ b/src/smf/smfd/SmfCampState.cc
> @@ -191,6 +191,18 @@ SmfCampState::commit(SmfUpgradeCampaign
>   }
>   
>   
> //--
> +// asyncFailure()
> +//--
> +SmfCampResultT
> +SmfCampState::asyncFailure(SmfUpgradeCampaign *  i_camp)
> +{
> + TRACE_ENTER();
> + LOG_NO("SmfCampState::asyncFailure default implementation. No state 
> change");
> + TRACE_LEAVE();
> +return SMF_CAMP_DONE;
> +}
> +
> +//--
>   // procResult()
>   
> //--
>   SmfCampResultT
> @@ -926,6 +938,37 @@ SmfCampStateExecuting::suspend(SmfUpgrad
>   }
>   
>   
> //--
> +// asyncFailure()
> +//--
> +SmfCampResultT
> +SmfCampStateExecuting::asyncFailure(SmfUpgradeCampaign * i_camp)
> +{
> + TRACE_ENTER();
> + TRACE("SmfCampStateExecuting::asyncFailure implementation");
> +
> + /* Send suspend message to all procedures */
> +std::vector procedures = 
> i_camp->getProcedures();
> +
> + std::vector < SmfUpgradeProcedure * >::iterator iter;
> +
> + for (iter = procedures.begin(); iter != procedures.end(); ++iter) {
> +TRACE("SmfCampStateExecuting::Procedure %s, send suspend",
> +  (*iter)->getProcName().c_str());
> +SmfProcedureThread *procThread = (*iter)->getProcThread();
> +PROCEDURE_EVT *evt = new PROCEDURE_EVT();
> +evt->type = PROCEDURE_EVT_SUSPEND;
> +procThread->send(evt);
> + }
> +
> +i_camp->m_noOfProcResponses = 0;
> +changeState(i_camp, SmfCampStateErrorDetected::instance());
> +/* Wait for suspend responses from all procedures 
> (SmfCampStateSuspendingExec::procResult) */
> +
> + TRACE_LEAVE();
> +return SMF_CAMP_SUSPENDING;
> +}
> +
> +//--
>   // procResult()
>   
> //--
>   SmfCampResultT
> @@ -1215,6 +1258,19 @@ SmfCampStateSuspendingExec::execute(SmfU
>   }
>   
>   
> //--
> +// asyncFailure()
> +//--
> +SmfCampResultT
> +SmfCampStateSuspendingExec::asyncFailure(SmfUpgradeCampaign * i_camp)
> +{
> + TRACE_ENTER();
> + TRACE("SmfCampStateSuspendingExec::asyncFailure implementation");
> + changeState(i_camp, SmfCampStateErrorDetectedInSuspending::instance());
> + TRACE_LEAVE();
> + return SMF_CAMP_DONE;
> +}
> +
> +//--
>   // procResult()
>   
> //--
>   SmfCampResultT
> @@ -1991,6 +2047,18 @@ SmfCampRollingBack::suspend(SmfUpgradeCa
>   }
>   
>   
> //--
> +// asyncFailure()
> +//--
> +SmfCampResultT
> +SmfCampRollingBack::asyncFailure(SmfUpgradeCampaign * i_camp)
> +{
> + TRACE_ENTER();
> + TRACE("SmfCampRollingBack::asyncFailure implementation");
> +
> +  return SmfCampRollingBack::suspend(i_camp);
> +}
> +
> +//--
>   // procResult()
>   
> //--
>   SmfCampResultT
> diff --git a/src/smf/smfd/SmfCampState.h b/src/smf/smfd/SmfCampState.h
> --- a/src/smf/smfd/SmfCampState.h
> +++ b/src/smf/smfd/SmfCampState.h
> @@ -72,6 +72,8 @@ class SmfCampState {
>   
>   virtual SmfCampResultT commit(SmfUpgradeCampaign * i_camp);
>   
> + virtual SmfCampResultT 

Re: [devel] [PATCH 1 of 1] imm: init CLM in seperate thread to avoid deadlock [#2327] V2

[Neelakanta Reddy]

Hi Hung,

yes, will update the comment while pushing.

Thanks,
Neel.

On 2017/03/03 12:17 PM, Hung Nguyen wrote:
> Hi Neel,
>
> Reviewed and tested the patch.
> Ack from me with a minor comment.
>
> After finalizing clm handle, we should set immnd_cb->clmSelectionObject to -1.
>   if(error == SA_AIS_ERR_BAD_HANDLE){
>   LOG_NO("Re-initializing with CLMS");
>   saClmFinalize(immnd_cb->clm_hdl);
>   immnd_clm_node_cleanup(immnd_cb);
>   immnd_init_with_clm();
>   }
>
> BR,
> Hung Nguyen - DEK Technologies
>
> 
> From: Neelakanta reddyreddy.neelaka...@oracle.com
> Sent: Thursday, March 02, 2017 2:31PM
> To: Hung Nguyen, Zoran Milinkovic
>  hung.d.ngu...@dektech.com.au,zoran.milinko...@ericsson.com
> Cc: Opensaf-devel
>  opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] imm: init CLM in seperate thread to avoid deadlock 
> [#2327] V2
>
>
>   src/imm/immnd/immnd_clm.c  |  30 +++---
>   src/imm/immnd/immnd_main.c |   2 ++
>   2 files changed, 29 insertions(+), 3 deletions(-)
>
>
> diff --git a/src/imm/immnd/immnd_clm.c b/src/imm/immnd/immnd_clm.c
> --- a/src/imm/immnd/immnd_clm.c
> +++ b/src/imm/immnd/immnd_clm.c
> @@ -160,7 +160,7 @@ static const SaClmCallbacksT_4 clm_callb
>*  Return Values : None.
>*
>
> /
> -void immnd_init_with_clm(void)
> +void *immnd_clm_init_thread(void *cb)
>   {
>   SaAisErrorT rc = SA_AIS_OK;
>   
> @@ -192,7 +192,31 @@ void immnd_init_with_clm(void)
>   }
>   TRACE("CLM Initialization SUCCESS..");
>   TRACE_LEAVE();
> -//return NULL;
> -return ;
> +return NULL;
> +}
> +/
> + * Name : immnd_init_with_clm
> + *
> + * Description :
> + *  initialize clm thread
> + *
> + * Return Values : None.
> + *
> +/
> +void immnd_init_with_clm(void)
> +{
> +pthread_t thread;
> +pthread_attr_t attr;
> +TRACE_ENTER();
> +
> +pthread_attr_init();
> +pthread_attr_setdetachstate(, PTHREAD_CREATE_DETACHED);
> +
> +if (pthread_create(, , immnd_clm_init_thread, immnd_cb) 
> != 0) {
> +LOG_ER("pthread_create FAILED: %s", strerror(errno));
> +exit(EXIT_FAILURE);
> +}
> +pthread_attr_destroy();
> +TRACE_LEAVE();
>   }
>   
> diff --git a/src/imm/immnd/immnd_main.c b/src/imm/immnd/immnd_main.c
> --- a/src/imm/immnd/immnd_main.c
> +++ b/src/imm/immnd/immnd_main.c
> @@ -340,6 +340,8 @@ int main(int argc, char *argv[])
>   struct timespec passed_time;
>   osaf_timespec_subtract(, _time, _time);
>   uint64_t passed_time_ms = osaf_timespec_to_millis(_time);
> + fds[FD_CLM].fd = immnd_cb->clmSelectionObject;
> + fds[FD_CLM].events = POLLIN;
>   
>   
>   maxEvt = (timeout == 100) ? 50 : 100;
>

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

Re: [devel] [PATCH 1 of 1] amf: support restrictions to auto-repair [#2144]

[Neelakanta Reddy]

Hi Alex,

The included patches are: latest #2144 patch provided by praveen with 
latest #2145 patch.

The Rolling upgrade campaign to change the application version is failing.
This is basic application upgrade test.

  # smf-state camp
safSmfCampaign=Campaign1,safApp=safSmfService
 state=ERROR_DETECTED(7)
 error='safSu=dummy_2n_1,safSg=SG_dummy_2n,safApp=2nApp failed 
after upgrade'

syslog:
Mar 27 08:10:57 SLES1 osafsmfd[29847]: NO PROC: Procedure init actions 
completed
Mar 27 08:10:57 SLES1 osafsmfd[29847]: NO PROC: Start executing the steps
Mar 27 08:10:57 SLES1 osafsmfd[29847]: NO STEP: Executing AU restart 
step 
safSmfStep=0001,safSmfProc=amfClusterProc-1,safSmfCampaign=Campaign1,safApp=safSmfService
Mar 27 08:10:57 SLES1 osafsmfd[29847]: NO STEP: Online installation of 
new software
Mar 27 08:10:57 SLES1 osafsmfnd[29845]: NO Successful start of command 
execution: /hostfs/online_install.sh bundle-new, timeout 8
Mar 27 08:10:57 SLES1 osafsmfnd[29845]: NO Command execution OK
Mar 27 08:10:57 SLES1 osafsmfd[29847]: NO STEP: Create new 
SaAmfNodeSwBundle objects
Mar 27 08:10:57 SLES1 osafimmnd[29768]: NO Ccb 54 COMMITTED (SMFSERVICE)
Mar 27 08:10:57 SLES1 osafsmfd[29847]: NO STEP: Modify information model 
and set maintenance status
Mar 27 08:10:57 SLES1 osafimmnd[29768]: NO Ccb 55 COMMITTED (SMFSERVICE)
Mar 27 08:10:57 SLES1 osafamfnd[29829]: NO saAmfCompType changed to 
'safVersion=6.0.0,safCompType=Comp_2nApp_2n_1_1' for 
'safComp=Norm1,safSu=dummy_2n_1,safSg=SG_dummy_2n,safApp=2nApp'
Mar 27 08:10:57 SLES1 osafimmnd[29768]: NO Ccb 56 COMMITTED (SMFSERVICE)
Mar 27 08:10:57 SLES1 osafsmfd[29847]: NO STEP: Restart activation units
Mar 27 08:10:57 SLES1 osafamfnd[29829]: NO Admin restart requested for 
'safComp=Norm1,safSu=dummy_2n_1,safSg=SG_dummy_2n,safApp=2nApp'
Mar 27 08:10:57 SLES1 osafamfnd[29829]: NO not restarting comp because 
maintenance campaign is set: safSmfCampaign=Campaign1,safApp=safSmfService
Mar 27 08:10:57 SLES1 osafsmfd[29847]: ER SU: 
safSu=dummy_2n_1,safSg=SG_dummy_2n,safApp=2nApp failed after upgrade in 
campaign

Thanks,
Neel.



On 2017/03/03 02:55 AM, Alex Jones wrote:
> Hi Praveen,
>
>Both patches look fine except for one issue in the first patch
> (02_2144.patch). See the comment below.
>
> Neel, do you have any comments for the SMF patch?
>
>If both of you guys are OK, then I will push the AMF (my original and
> Praveen's 2 later ones) and SMF patches tomorrow.
>
> Alex
>
> 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
> @@ -2092,13 +2092,17 @@ void avd_node_down_mw_susi_failover(AVD_
> * one loop as more than one MW SU per SG in one node is not supported.
> */
>osafassert(avnd->list_of_ncs_su.empty() != true);
> -
> + bool campaign_set = avnd->is_campaign_set_for_all_sus();
>for (const auto& i_su : avnd->list_of_ncs_su) {
> +   if ((avnd->saAmfNodeAdminState != SA_AMF_ADMIN_LOCKED_INSTANTIATION) ||
> +   (campaign_set == false)) {
> + i_su->set_oper_state(SA_AMF_OPERATIONAL_DISABLED);
> + i_su->disable_comps(SA_AIS_ERR_TIMEOUT);
> +   }
>
> [Alex] The following line needs to be removed.
>  i_su->set_oper_state(SA_AMF_OPERATIONAL_DISABLED);
> [Alex] Done comment
>  i_su->set_pres_state(SA_AMF_PRESENCE_UNINSTANTIATED);
>
> On 03/01/2017 04:10 AM, praveen malviya wrote:
>> 
>> NOTICE: This email was received from an EXTERNAL sender
>> 
>>
>> Hi Alex,
>>
>> Change in comp.cc looks fine.
>>
>> I guess other changes are related to the node reboot case in the context
>> of a campaign which performs upgrade by rebooting the node. In this case
>> since amfnd is freshly coming up, SUs on this node will not have their
>> sumaintenance attribute set (amfnd does not read su config from IMM)
>> which was set before SMF orders node reboot. If this is the case then I
>> think this can still be achieved without updating AMFD and AMFND MDS
>> versions and without including it in SU_REG message.
>>
>> How to do it: AMFD still can send campaign name by calling
>> su->set_su_maintenance_campaign() for each SU when it gets response from
>> amfnd for SU_REG successful and before it sends instantiation message
>> for any SU. By this time AMFND has already all the information of SU
>> hosted on it, so it will update the su_db with campaign name. Attached
>> is the patch based on this idea (2144_update.patch).
>>
>> Thanks,
>> Praveen
>>
>>
>> On 01-Mar-17 3:01 AM, Alex Jones wrote:
>>> src/amf/amfd/mds.cc | 2 +-
>>> src/amf/amfd/mds.h | 4 ++--
>>> src/amf/amfd/util.cc | 5 +
>>> src/amf/amfnd/avnd_mds.h | 4 ++--
>>> src/amf/amfnd/comp.cc | 2 +-
>>> src/amf/amfnd/mds.cc | 4 ++--
>>> src/amf/amfnd/sudb.cc | 2 ++
>>> src/amf/common/amf_d2nmsg.h | 2 ++
>>> src/amf/common/d2nedu.c | 6 ++
>>> src/amf/common/d2nmsg.c 

Re: [devel] [PATCH 1 of 1] imm: init CLM in seperate thread to avoid deadlock [#2327]

[Neelakanta Reddy]

Hi Hung,

I missed adding below lines to the patch, which will reassign fd to poll.

diff --git a/src/imm/immnd/immnd_main.c b/src/imm/immnd/immnd_main.c
--- a/src/imm/immnd/immnd_main.c
+++ b/src/imm/immnd/immnd_main.c
@@ -340,6 +340,8 @@ int main(int argc, char *argv[])
 struct timespec passed_time;
 osaf_timespec_subtract(, _time, _time);
 uint64_t passed_time_ms = 
osaf_timespec_to_millis(_time);
+   fds[FD_CLM].fd = immnd_cb->clmSelectionObject;
+   fds[FD_CLM].events = POLLIN;


 maxEvt = (timeout == 100) ? 50 : 100;

Re-publish the patch, again.

Thanks,
Neel.

On 2017/03/02 09:36 AM, Hung Nguyen wrote:
> Hi Neel,
>
> Basic test failed. It doesn't return ERR_UNAVAILABLE when I lock the clm node.
> (I already use the latest version { 'A', 0x02, 0x12 } when initialize the 
> handle)
>
> BR,
> Hung Nguyen - DEK Technologies
>
> 
> From: Neelakanta reddyreddy.neelaka...@oracle.com
> Sent: Wednesday, March 01, 2017 3:26PM
> To: Hung Nguyen, Zoran Milinkovic
>  hung.d.ngu...@dektech.com.au,zoran.milinko...@ericsson.com
> Cc: Opensaf-devel
>  opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] imm: init CLM in seperate thread to avoid deadlock 
> [#2327]
>
>
>   src/imm/immnd/immnd_clm.c |  30 +++---
>   1 files changed, 27 insertions(+), 3 deletions(-)
>
>
> diff --git a/src/imm/immnd/immnd_clm.c b/src/imm/immnd/immnd_clm.c
> --- a/src/imm/immnd/immnd_clm.c
> +++ b/src/imm/immnd/immnd_clm.c
> @@ -160,7 +160,7 @@ static const SaClmCallbacksT_4 clm_callb
>*  Return Values : None.
>*
>
> /
> -void immnd_init_with_clm(void)
> +void *immnd_clm_init_thread(void *cb)
>   {
>   SaAisErrorT rc = SA_AIS_OK;
>   
> @@ -192,7 +192,31 @@ void immnd_init_with_clm(void)
>   }
>   TRACE("CLM Initialization SUCCESS..");
>   TRACE_LEAVE();
> -//return NULL;
> -return ;
> +return NULL;
> +}
> +/
> + * Name : immnd_init_with_clm
> + *
> + * Description :
> + *  initialize clm thread
> + *
> + * Return Values : None.
> + *
> +/
> +void immnd_init_with_clm(void)
> +{
> +pthread_t thread;
> +pthread_attr_t attr;
> +TRACE_ENTER();
> +
> +pthread_attr_init();
> +pthread_attr_setdetachstate(, PTHREAD_CREATE_DETACHED);
> +
> +if (pthread_create(, , immnd_clm_init_thread, immnd_cb) 
> != 0) {
> +LOG_ER("pthread_create FAILED: %s", strerror(errno));
> +exit(EXIT_FAILURE);
> +}
> +pthread_attr_destroy();
> +TRACE_LEAVE();
>   }
>   
>

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

Re: [devel] [PATCH 1 of 1] imm: init CLM in seperate thread to avoid deadlock [#2327]

[Neelakanta Reddy]

Hi zoran,

The patch must also include the below lines after while(1) in immnd_main.c,
which will set correct fd to fds[FD_CLM].fd, when it is set in the thread.


diff --git a/src/imm/immnd/immnd_main.c b/src/imm/immnd/immnd_main.c
--- a/src/imm/immnd/immnd_main.c
+++ b/src/imm/immnd/immnd_main.c
@@ -340,6 +340,8 @@ int main(int argc, char *argv[])
 struct timespec passed_time;
 osaf_timespec_subtract(, _time, _time);
 uint64_t passed_time_ms = 
osaf_timespec_to_millis(_time);
+   fds[FD_CLM].fd = immnd_cb->clmSelectionObject;
+   fds[FD_CLM].events = POLLIN;

Re-publish the patch again, by including the changes.

Thanks,
Neel.

On 2017/03/01 06:48 PM, Zoran Milinkovic wrote:
> Hi,
>
> Ok, it's set to -1, and it means that FD_CLM fd will not be used.
> I don't still see where the correct clmSelectionObject will be set to 
> fds[FD_CLM].fd
>
> In the block I commented, -1 or the correct clmSelectionObject (if creating 
> thread and then CLM initialization is very quick) can be set to fds[FD_CLM].fd
>
> My point is that first immnd_init_with_clm() is called which create a thread 
> for initialization of CLM. Then just after the call, 
> immnd_cb->clmSelectionObject is set to fds[FD_CLM].fd.
> I don't see how creating a new thread + saClmInitialize_4() call + 
> saClmSelectionObjectGet() call is faster than executing immnd_init_with_clm() 
> and fds[FD_CLM].fd = immnd_cb->clmSelectionObject;
>
> Thanks,
> Zoran
>
> -Original Message-
> From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
> Sent: den 1 mars 2017 13:34
> To: Zoran Milinkovic <zoran.milinko...@ericsson.com>; Hung Duc Nguyen 
> <hung.d.ngu...@dektech.com.au>
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 1 of 1] imm: init CLM in seperate thread to avoid 
> deadlock [#2327]
>
> Hi Zoran,
>
> immnd_cb->clmSelectionObject is set to -1 in immnd_initialize(it will not be 
> 0).
>
> Thanks,
> Neel.
>
>
>
> On 2017/03/01 05:28 PM, Zoran Milinkovic wrote:
>> Hi Neelakanta,
>>
>> Our testers say that the patch work, but I'm still stuck with some parts.
>>
>> In the code in the main():
>>  if (fds[FD_CLM_INIT].revents & POLLIN && !immnd_cb->clm_hdl) {
>>  TRACE("Initalize CLM ");
>>  ncs_sel_obj_rmv_ind(_cb->clm_init_sel_obj, true, true);
>>  immnd_init_with_clm();
>>  nfds=5;
>>  fds[FD_CLM].fd = immnd_cb->clmSelectionObject;
>>  fds[FD_CLM].events = POLLIN;
>>  }
>> You assign fds[FD_CLM].fd to immnd_cb->clmSelectionObject while 
>> clmSelectionObject still cannot be obtain since its value is set in a 
>> running thread.
>> If any CLM function has a small delay in its execution, or the thread 
>> execution is a bit delayed, then fds[FD_CLM].fd will be populated with wrong 
>> file descriptor.
>> I guess it will be 0 and then FD_CLM will listen events from standard input. 
>> It means that CLM callbacks will never been received.
>>
>> BR,
>> Zoran
>>
>> -Original Message-
>> From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
>> Sent: den 1 mars 2017 12:06
>> To: Zoran Milinkovic <zoran.milinko...@ericsson.com>; Hung Duc Nguyen
>> <hung.d.ngu...@dektech.com.au>
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [PATCH 1 of 1] imm: init CLM in seperate thread to avoid
>> deadlock [#2327]
>>
>> Hi Zoran,
>>
>> comments inline.
>>
>> On 2017/03/01 03:43 PM, Zoran Milinkovic wrote:
>>> Hi Neelakanta,
>>>
>>> How does the code ensure that more threads will not be created and start 
>>> initializing more CLMs at once ?
>> Thread is called only once, If the clmInitialization fails with TRY_AGAIN or 
>> TIMEOUT, there is TRY_AGAIN loop in function immnd_init_with_clm.
>>
>> rc = saClmInitialize_4(_cb->clm_hdl, _callbacks, );
>>while ((rc == SA_AIS_ERR_TRY_AGAIN) || (rc ==
>> SA_AIS_ERR_TIMEOUT) ||
>>(rc == SA_AIS_ERR_UNAVAILABLE)) {
>>osaf_nanosleep();
>>rc = saClmInitialize_4(_cb->clm_hdl,
>> _callbacks, );
>>}
>>
>> Thanks,
>> Neel.
>>
>>
>>> Thanks,
>>> Zoran
>>>
>>> -Original Message-
>>> From: reddy.neelaka...@oracle.com
>>> [mailto:reddy.neelaka...@oracle.com]
>>> Sent: den 1 mars 2017 09:27
>

Re: [devel] [PATCH 1 of 1] smfd: add support for asynchronous detection of failed AMF entities [#2145]

[Neelakanta Reddy]

aveen has acked the suMaintenanceCampaign changes in AMF. If I
> push this AMF change, but don't push the SMF changes, then if AMF sets
> oper state to disabled for an SU that has its suMaintenanceCampaign
> attribute set (which SMF already does), auto-repair will be disabled,
> and the SMF admin won't be told about it unless they look in the logs.
>
> (2) There is still an AMF change to not mark an SU disabled if the AMF
> node is in locked-in state, when SMF reboots the node (for rolling
> upgrade with reboot). If this change is not pushed, and the SMF changes
> are pushed, then rollback and undo will break in SMF for this case.
>
> (3) I don't think you guys have done much testing (if any) of the SMF
> patch because you wanted the AMF patch acked first, which makes sense.
> Is there enough time to test this?
>
> Alex
>
> On 02/27/2017 08:08 AM, Neelakanta Reddy wrote:
>> 
>> NOTICE: This email was received from an EXTERNAL sender
>> 
>>
>> Hi Alex,
>>
>> Are you Pushing(#2145) patch, along with #2144?
>>
>> Thanks,
>> Neel.
>>
>> On 2016/11/12 01:20 AM, Alex Jones wrote:
>>> osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc | 235
>> +-
>>> osaf/services/saf/smfsv/smfd/SmfCampaignThread.hh | 15 +
>>> osaf/services/saf/smfsv/smfd/SmfStepTypes.cc | 32 +-
>>> 3 files changed, 263 insertions(+), 19 deletions(-)
>>>
>>>
>>> This patch adds support for section 4.2.1.3 of SMF A.01.02 spec.
>>>
>>> diff --git a/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc
>> b/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc
>>> --- a/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc
>>> +++ b/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc
>>> @@ -39,6 +39,7 @@
>>> #include "SmfUtils.hh"
>>>
>>> SmfCampaignThread *SmfCampaignThread::s_instance = NULL;
>>> +SaNtfSubscriptionIdT SmfCampaignThread::operStateSubId(1);
>>>
>>> #define SMF_RDA_RETRY_COUNT 25 /* This is taken as the csi's are
>> assigned in parallel */
>>> @@ -140,7 +141,12 @@ void SmfCampaignThread::main(NCSCONTEXT
>>> SmfCampaignThread::~SmfCampaignThread()
>>> {
>>> TRACE_ENTER();
>>> - SaAisErrorT rc = saNtfFinalize(m_ntfHandle);
>>> + SaAisErrorT rc(saNtfNotificationUnsubscribe(operStateSubId));
>>> + if (rc != SA_AIS_OK) {
>>> + LOG_ER("Failed to unsubscribe to oper state notifications %u", rc);
>>> + }
>>> +
>>> + rc = saNtfFinalize(m_ntfHandle);
>>> if (rc != SA_AIS_OK) {
>>> LOG_ER("Failed to finalize NTF handle %u", rc);
>>> }
>>> @@ -303,10 +309,14 @@ int SmfCampaignThread::initNtf(void)
>>> {
>>> SaAisErrorT rc = SA_AIS_ERR_TRY_AGAIN;
>>> SaVersionT ntfVersion = { 'A', 1, 1 };
>>> + SaNtfCallbacksT callbacks = {
>>> + ntfNotificationCallback,
>>> + 0
>>> + };
>>> unsigned int numOfTries = 50;
>>>
>>> while (rc == SA_AIS_ERR_TRY_AGAIN && numOfTries > 0) {
>>> - rc = saNtfInitialize(_ntfHandle, NULL, );
>>> + rc = saNtfInitialize(_ntfHandle, , );
>>> if (rc != SA_AIS_ERR_TRY_AGAIN) {
>>> break;
>>> }
>>> @@ -319,9 +329,202 @@ int SmfCampaignThread::initNtf(void)
>>> return -1;
>>> }
>>>
>>> + // subscribe to operational state change notifications generated by AMF
>>> + rc = initNtfSubscriptions();
>>> + if (rc != SA_AIS_OK) {
>>> + LOG_ER("initNtfSubscriptions FAILED rc=%s", saf_error(rc));
>>> + return -1;
>>> + }
>>> +
>>> return 0;
>>> }
>>>
>>> +SaAisErrorT SmfCampaignThread::initNtfSubscriptions(void) {
>>> + TRACE_ENTER();
>>> + SaAisErrorT rc(SA_AIS_OK);
>>> +
>>> + do {
>>> + SaNtfStateChangeNotificationFilterT stateChangeFilter;
>>> +
>>> + SaAisErrorT rc(saNtfStateChangeNotificationFilterAllocate(
>>> + m_ntfHandle,
>>> + ,
>>> + 0,
>>> + 0,
>>> + 0,
>>> + 0,
>>> + 0,
>>> + 0));
>>> +
>>> + if (rc != SA_AIS_OK) {
>>> + LOG_ER("saNtfAttributeChangeNotificationFilterAllocate FAILED rc=%s",
>>> + saf_error(rc));
>>> + break;
>>> + }
>>> +
>>> + SaNtfNotificationTypeFilterHandlesT notificationFilterHandles = {
>>

Re: [devel] [PATCH 1 of 1] smfd: add support for asynchronous detection of failed AMF entities [#2145]

[Neelakanta Reddy]

Hi Alex,

Are you Pushing(#2145) patch, along with #2144?

Thanks,
Neel.

On 2016/11/12 01:20 AM, Alex Jones wrote:
>   osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc |  235 
> +-
>   osaf/services/saf/smfsv/smfd/SmfCampaignThread.hh |   15 +
>   osaf/services/saf/smfsv/smfd/SmfStepTypes.cc  |   32 +-
>   3 files changed, 263 insertions(+), 19 deletions(-)
>
>
> This patch adds support for section 4.2.1.3 of SMF A.01.02 spec.
>
> diff --git a/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc 
> b/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc
> --- a/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc
> +++ b/osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc
> @@ -39,6 +39,7 @@
>   #include "SmfUtils.hh"
>   
>   SmfCampaignThread *SmfCampaignThread::s_instance = NULL;
> +SaNtfSubscriptionIdT SmfCampaignThread::operStateSubId(1);
>   
>   #define SMF_RDA_RETRY_COUNT 25 /* This is taken as the csi's are assigned 
> in parallel */
>   
> @@ -140,7 +141,12 @@ void SmfCampaignThread::main(NCSCONTEXT
>   SmfCampaignThread::~SmfCampaignThread()
>   {
>   TRACE_ENTER();
> - SaAisErrorT rc = saNtfFinalize(m_ntfHandle);
> +  SaAisErrorT rc(saNtfNotificationUnsubscribe(operStateSubId));
> + if (rc != SA_AIS_OK) {
> + LOG_ER("Failed to unsubscribe to oper state notifications %u", 
> rc);
> + }
> +
> + rc = saNtfFinalize(m_ntfHandle);
>   if (rc != SA_AIS_OK) {
>   LOG_ER("Failed to finalize NTF handle %u", rc);
>   }
> @@ -303,10 +309,14 @@ int SmfCampaignThread::initNtf(void)
>   {
>   SaAisErrorT rc = SA_AIS_ERR_TRY_AGAIN;
>   SaVersionT ntfVersion = { 'A', 1, 1 };
> +  SaNtfCallbacksT callbacks = {
> +ntfNotificationCallback,
> +0
> +  };
>   unsigned int numOfTries = 50;
>   
>   while (rc == SA_AIS_ERR_TRY_AGAIN && numOfTries > 0) {
> - rc = saNtfInitialize(_ntfHandle, NULL, );
> + rc = saNtfInitialize(_ntfHandle, , );
>   if (rc != SA_AIS_ERR_TRY_AGAIN) {
>   break;
>   }
> @@ -319,9 +329,202 @@ int SmfCampaignThread::initNtf(void)
>   return -1;
>   }
>   
> +  // subscribe to operational state change notifications generated by AMF
> +  rc = initNtfSubscriptions();
> + if (rc != SA_AIS_OK) {
> + LOG_ER("initNtfSubscriptions FAILED rc=%s", saf_error(rc));
> + return -1;
> + }
> +
>   return 0;
>   }
>   
> +SaAisErrorT SmfCampaignThread::initNtfSubscriptions(void) {
> +  TRACE_ENTER();
> +  SaAisErrorT rc(SA_AIS_OK);
> +
> +  do {
> +SaNtfStateChangeNotificationFilterT stateChangeFilter;
> +
> +SaAisErrorT rc(saNtfStateChangeNotificationFilterAllocate(
> +  m_ntfHandle,
> +  ,
> +  0,
> +  0,
> +  0,
> +  0,
> +  0,
> +  0));
> +
> +if (rc != SA_AIS_OK) {
> +  LOG_ER("saNtfAttributeChangeNotificationFilterAllocate FAILED rc=%s",
> + saf_error(rc));
> +  break;
> +}
> +
> +SaNtfNotificationTypeFilterHandlesT notificationFilterHandles = {
> +  0,
> +  0,
> +  stateChangeFilter.notificationFilterHandle,
> +  0,
> +  0
> +};
> +
> +rc = saNtfNotificationSubscribe(, 
> operStateSubId);
> +
> +if (rc != SA_AIS_OK) {
> +  LOG_ER("saNtfNotificationSubscribe FAILED rc=%s", saf_error(rc));
> +  break;
> +}
> +
> +rc = 
> saNtfNotificationFilterFree(stateChangeFilter.notificationFilterHandle);
> +if (rc != SA_AIS_OK) {
> +  LOG_ER("saNtfNotificationFilterFree FAILED rc=%s", saf_error(rc));
> +  break;
> +}
> +  } while (false);
> +
> +  TRACE_LEAVE();
> +  return rc;
> +}
> +
> +bool SmfCampaignThread::isAMFOperState(const SaNtfClassIdT& classId) const {
> +  TRACE_ENTER();
> +  bool status(false);
> +
> +  if (classId.vendorId == SA_NTF_VENDOR_ID_SAF &&
> +  classId.majorId == SA_SVC_AMF &&
> +  classId.minorId == SA_AMF_NTFID_SU_OP_STATE) {
> +status = true;
> +  }
> +
> +  TRACE_LEAVE2("%i", status);
> +  return status;
> +}
> +
> +void SmfCampaignThread::handleStateChangeNotification(
> +  const SaNtfStateChangeNotificationT& stateChangeNotification) {
> +  TRACE_ENTER();
> +  if (stateChangeNotification.notificationHeader.eventType) {
> +if (*stateChangeNotification.notificationHeader.eventType ==
> +  SA_NTF_OBJECT_STATE_CHANGE) {
> +  handleObjectStateChangeNotification(stateChangeNotification);
> +} else {
> +  TRACE("ignoring state change notification with event type: %i",
> +*stateChangeNotification.notificationHeader.eventType);
> +}
> +  }
> +  TRACE_LEAVE();
> +}
> +
> +void SmfCampaignThread::handleAmfObjectStateChangeNotification(
> +  const SaNtfStateChangeNotificationT& stateChangeNotification) {
> +  TRACE_ENTER();
> +
> +  do {
> +bool disabled(false);
> +
> +// see if this is a failure of an upgraded SU
> +for (SaUint16T i(0); i < stateChangeNotification.numStateChanges; i++) {
> + 

Re: [devel] [PATCH 0 of 1] Review Request for imm: Cleanup orphaned implementers and admowners when headless [#2309]

[Neelakanta Reddy]

Hi Hung,

got it.

Reviewed the patch.
Ack.

Thanks,
Neel.

On 2017/02/21 01:01 PM, Hung Nguyen wrote:
> Hi Neel,
>
> The problem is,
> in immnd_proc_discard_other_nodes(), it fails to use 
> immnd_client_node_getnext() to get the client_node associated to the OI that 
> being discarded.
> The reason is the client_node has already been removed from 
> cb->client_info_db when the client was killed.
>
> I had imm traces attched to the ticket, you can look at the traces.
>
> Feb 15 10:57:20.674683 osafimmnd [1127:src/imm/immnd/ImmModel.cc:13713] NO 
> Implementer locally disconnected. Marking it as doomed 6 <29, 2030f> (xhunngu)
> Feb 15 10:57:20.674763 osafimmnd [1127:src/imm/immnd/ImmModel.cc:13737] << 
> discardImplementer
> Feb 15 10:57:20.674790 osafimmnd [1127:src/imm/immnd/immnd_proc.c:0242] T5 
> Discard connection id:1d0002030f succeeded
> Feb 15 10:57:20.674873 osafimmnd [1127:src/imm/immnd/immnd_proc.c:0245] << 
> immnd_proc_imma_discard_connection
> Feb 15 10:57:20.674892 osafimmnd [1127:src/imm/immnd/immnd_proc.c:0275] T5 
> Removing client id:1d0002030f sv_id:27
> Feb 15 10:57:20.674912 osafimmnd [1127:src/imm/immnd/immnd_proc.c:0292] T5 
> Removed 1 IMMA clients
> Feb 15 10:57:20.674951 osafimmnd [1127:src/imm/common/immsv_evt.c:5421] T8 
> Received: IMMND_EVT_MDS_INFO (1) from 0
>
>
>   if (immnd_proc_imma_discard_connection(cb, cl_node, 
> false)) {
>   TRACE_5("Removing client id:%llx sv_id:%u", 
> cl_node->imm_app_hdl, cl_node->sv_id);
>   immnd_client_node_del(cb, cl_node);
>   memset(cl_node, '\0', 
> sizeof(IMMND_IMM_CLIENT_NODE));
>
> BR,
> Hung Nguyen - DEK Technologies
>
> 
> From: Neelakanta reddyreddy.neelaka...@oracle.com
> Sent: Monday, February 20, 2017 6:15PM
> To: Hung Nguyen, Zoran Milinkovic
>  hung.d.ngu...@dektech.com.au,zoran.milinko...@ericsson.com
> Cc: Opensaf-devel
>  opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 0 of 1] Review Request for imm: Cleanup orphaned 
> implementers and admowners when headless [#2309]
>
>
> Hi Hung,
>
> The local implementers will be discarded in 
> "immnd_proc_discard_other_nodes"  while discarding clients.
> The implementers from the other node will be discarded in 
> immModel_isolateThisNode.
>
> If the IMMD broadcast misses also this should be covered in either of 
> the above.
>
> /Neel.
>
> On 2017/02/17 01:35 PM, Hung Nguyen wrote:
>> Summary: imm: Cleanup orphaned implementers and admowners when 
>> headless [#2309]
>> Review request for Trac Ticket(s): 2309
>> Peer Reviewer(s): Zoran, Neel
>> Pull request to:
>> Affected branch(es): 5.0, 5.1, 5.2
>> Development branch: 5.2
>>
>> 
>> 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 d79e3d47468b927dd5b06f2efa869a63380fe3c4
>> Author:Hung Nguyen 
>> Date:Fri, 17 Feb 2017 15:03:49 +0700
>>
>> imm: Cleanup orphaned implementers and admowners when headless 
>> [#2309]
>>
>> If a client is down right before headless, chances are the 
>> implementers and
>> admowners will be orphaned because IMMD fails to broadcast global 
>> discard
>> messages. This patch cleans those orphaned implementers and 
>> admowners up.
>>
>>
>> Complete diffstat:
>> --
>>   src/imm/immnd/ImmModel.cc |  31 ++-
>>   1 files changed, 18 insertions(+), 13 deletions(-)
>>
>>
>> Testing Commands:
>> -
>> Kill client right before headless.
>>
>>
>> Testing, Expected Results:
>> --
>> No orphaned implementers or admowners.
>>
>>
>> Conditions of Submission:
>> -
>> Ack from reviewers.
>>
>>
>> Arch  Built StartedLinux distro
>> ---
>> mipsn  n
>> mips64  n  n
>> x86 n  n
>> x86_64  n  n
>> powerpc n  n
>> powerpc64   n  n
>>
>>
>> Reviewer Checklist:
>> ---
>> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>>
>>
>> Your checkin has not passed review because (see checked entries):
>>
>> ___ Your RR template is generally incomplete; it has too many blank 
>> entries
>>  that need proper data filled in.
>>
>> ___ You have failed to nominate the proper persons for review and push.
>>
>> ___ 

Re: [devel] [PATCH 0 of 3] Review Request for Integrate IMM service with CLM [#1640]

[Neelakanta Reddy]

Forgot to hg add the newly created file, will send the next version of 
the patch

Thanks,
Neel.

On 2017/02/21 11:08 AM, reddy.neelaka...@oracle.com wrote:
> Summary:  Integrate IMM service with CLM [#1640]
> Review request for Trac Ticket(s): 1640
> Peer Reviewer(s): Zoran, Hung
> Affected branch(es): default
> Development branch: default
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -----
>
> changeset 88d7dc2e8243d138078cefc965ddd799e4fa2c4c
> Author:   Neelakanta Reddy <reddy.neelaka...@oracle.com>
> Date: Tue, 21 Feb 2017 10:51:31 +0530
>
>   imm: README changes for integrating IMM with CLMS [#1640]
>
> changeset 5e544f27cfdbb3aca7d11e3d6b5ab94828a1e825
> Author:   Neelakanta Reddy <reddy.neelaka...@oracle.com>
> Date: Tue, 21 Feb 2017 10:53:46 +0530
>
>   imm: imm agent changes for integrating IMM with CLMS [#1640]
>
> changeset 2ba31b84493b426d744054df8ff82f92a9a49d11
> Author:   Neelakanta Reddy <reddy.neelaka...@oracle.com>
> Date: Tue, 21 Feb 2017 10:54:17 +0530
>
>   imm: immnd changes for integrating IMM with CLMS [#1640]
>
>
> Complete diffstat:
> --
>   src/imm/Makefile.am   |5 +++-
>   src/imm/README|   40 +++-
>   src/imm/agent/imma_cb.h   |   11 ++--
>   src/imm/agent/imma_db.cc  |   37 -
>   src/imm/agent/imma_init.cc|2 +
>   src/imm/agent/imma_oi_api.cc  |   96 
> +---
>   src/imm/agent/imma_om_api.cc  |  211 
> +++
>   src/imm/agent/imma_proc.cc|   31 
>   src/imm/common/immsv_api.h|3 +-
>   src/imm/common/immsv_evt.c|   15 +++
>   src/imm/common/immsv_evt.h|2 +
>   src/imm/immnd/ImmModel.cc |   44 ++
>   src/imm/immnd/ImmModel.h  |2 +
>   src/imm/immnd/immnd_cb.h  |   18 ++
>   src/imm/immnd/immnd_db.c  |  125 
> +++
>   src/imm/immnd/immnd_evt.c |   31 ---
>   src/imm/immnd/immnd_init.h|7 +
>   src/imm/immnd/immnd_main.c|   42 +++--
>   src/imm/immnd/immnd_mds.c |   30 +++-
>   src/nid/nodeinit.conf.payload |2 +-
>   20 files changed, 711 insertions(+), 43 deletions(-)
>
>
> Testing Commands:
> -
> Test new IMM agent version A.02.18.
> CLM membership status (when CLM is locked/unlocked) will be sent to agent, 
> only when agent is registered with A.02.18.
>
> old agent versions must work as it is.
>
> check the upgrade path from 5.1 to default(5.2)
>
> In case of CLM node lock, and HEADLESS is triggered after CLM node lock, then 
> CLM locked node
> is nullified. The node is considered as HEADLESS and all other agent 
> functions supported in HEADLESS
> are supported.
>
> Testing, Expected Results:
> --
> when agent is connected with version A.02.18 CLM membership status will be 
> reflected at agent
> when agent is connected with older versions, no CLM status will be sent to 
> agent.
>
> 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.
>
> _

Re: [devel] [PATCH 0 of 1] Review Request for imm: Cleanup orphaned implementers and admowners when headless [#2309]

[Neelakanta Reddy]

Hi Hung,

The local implementers will be discarded in 
"immnd_proc_discard_other_nodes"  while discarding clients.
The implementers from the other node will be discarded in 
immModel_isolateThisNode.

If the IMMD broadcast misses also this should be covered in either of 
the above.

/Neel.

On 2017/02/17 01:35 PM, Hung Nguyen wrote:
> Summary: imm: Cleanup orphaned implementers and admowners when headless 
> [#2309]
> Review request for Trac Ticket(s): 2309
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.0, 5.1, 5.2
> Development branch: 5.2
>
> 
> 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 d79e3d47468b927dd5b06f2efa869a63380fe3c4
> Author:   Hung Nguyen 
> Date: Fri, 17 Feb 2017 15:03:49 +0700
>
>   imm: Cleanup orphaned implementers and admowners when headless [#2309]
>
>   If a client is down right before headless, chances are the implementers 
> and
>   admowners will be orphaned because IMMD fails to broadcast global 
> discard
>   messages. This patch cleans those orphaned implementers and admowners 
> up.
>
>
> Complete diffstat:
> --
>   src/imm/immnd/ImmModel.cc |  31 ++-
>   1 files changed, 18 insertions(+), 13 deletions(-)
>
>
> Testing Commands:
> -
> Kill client right before headless.
>
>
> Testing, Expected Results:
> --
> No orphaned implementers or admowners.
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! 

Re: [devel] [PATCH 1 of 1] imm: fix PBE coredump for double freeing memory [#2304]

[Neelakanta Reddy]

Hi zoran,

Reviewed the patch.
Ack.

/Neel.

On 2017/02/13 06:10 PM, Zoran Milinkovic wrote:
>   src/imm/common/immpbe_dump.cc|  29 +++--
>   src/imm/immpbed/immpbe_daemon.cc |   2 ++
>   2 files changed, 21 insertions(+), 10 deletions(-)
>
>
> A static string variable sPbeFileName is double freed when exit call is 
> called from 2 threads.
> The patch dynamicly allocate the variable on pbeRepositoryInit call and free 
> the variable on pbeRepositoryClose call.
>
> diff --git a/src/imm/common/immpbe_dump.cc b/src/imm/common/immpbe_dump.cc
> --- a/src/imm/common/immpbe_dump.cc
> +++ b/src/imm/common/immpbe_dump.cc
> @@ -72,7 +72,7 @@ void pbeClosePrepareTrans()
>   #include 
>   #define STRINT_BSZ 32
>   
> -static std::string sPbeFileName;
> +static std::string *sPbeFileName;
>   
>   #define SQL_STMT_SIZE   31
>   
> @@ -598,6 +598,10 @@ void* pbeRepositoryInit(const char* file
>   };
>   TRACE_ENTER();
>   
> + if(!sPbeFileName) {
> + sPbeFileName = new std::string;
> + }
> +
>   if(!create) {goto re_attach;}
>   
>   /* Create a fresh Pbe-repository by dumping current imm contents to 
> (local or global)
> @@ -707,7 +711,7 @@ void* pbeRepositoryInit(const char* file
>   
>   prepareSqlStatements(dbHandle);
>   
> - sPbeFileName = std::string(filePath);
> + *sPbeFileName = std::string(filePath);
>   if (localTmpDir) free(localTmpDir);
>   TRACE_LEAVE();
>   return (void *) dbHandle;
> @@ -799,7 +803,7 @@ void* pbeRepositoryInit(const char* file
>   TRACE("Successfully executed %s", sql_tr[0]);
>   
>   
> - sPbeFileName = std::string(filePath); /* Avoid apend to presumed empty 
> string */
> + *sPbeFileName = std::string(filePath); /* Avoid apend to presumed empty 
> string */
>   
>   prepareSqlStatements(dbHandle);
>   
> @@ -826,6 +830,11 @@ void pbeRepositoryClose(void* dbHandle)
>   {
>   finalizeSqlStatements();
>   sqlite3_close((sqlite3 *) dbHandle);
> +
> + if(sPbeFileName) {
> + delete sPbeFileName;
> + sPbeFileName = NULL;
> + }
>   }
>   
>   void pbeCleanTmpFiles(std::string localTmpFilename)
> @@ -1537,7 +1546,7 @@ void objectModifyDiscardAllValuesOfAttrT
>   TRACE_LEAVE();
>   sqlite3_close((sqlite3 *) dbHandle);
>   if(badfile) {
> - discardPbeFile(sPbeFileName);
> + discardPbeFile(*sPbeFileName);
>   }
>   LOG_ER("Exiting (line:%u)", __LINE__);
>   exit(1);
> @@ -1783,7 +1792,7 @@ void objectModifyDiscardMatchingValuesOf
>   TRACE_LEAVE();
>   sqlite3_close((sqlite3 *) dbHandle);
>   if(badfile) {
> - discardPbeFile(sPbeFileName);
> + discardPbeFile(*sPbeFileName);
>   }
>
>   LOG_ER("Exiting (line:%u)", __LINE__);
> @@ -1974,7 +1983,7 @@ void objectModifyAddValuesOfAttrToPBE(vo
>bailout:
>   sqlite3_close((sqlite3 *) dbHandle);
>   if(badfile) {
> - discardPbeFile(sPbeFileName);
> + discardPbeFile(*sPbeFileName);
>   }
>   LOG_ER("Exiting (line:%u)", __LINE__);
>   exit(1);
> @@ -2301,7 +2310,7 @@ void objectDeleteToPBE(std::string objec
>bailout:
>   sqlite3_close((sqlite3 *) dbHandle);
>   if(badfile) {
> - discardPbeFile(sPbeFileName);
> + discardPbeFile(*sPbeFileName);
>   }
>   LOG_ER("Exiting (line:%u)", __LINE__);
>   exit(1);
> @@ -2584,7 +2593,7 @@ int verifyPbeState(SaImmHandleT immHandl
>   sqlite3_free_table(result);
>   sqlite3_close(dbHandle);
>   if(badfile) {
> - discardPbeFile(sPbeFileName);
> + discardPbeFile(*sPbeFileName);
>   }
>   LOG_WA("verifyPbeState failed!");
>   return 0;
> @@ -3103,7 +3112,7 @@ SaAisErrorT getCcbOutcomeFromPbe(void* d
>bailout:
>   sqlite3_close(dbHandle);
>   if(badfile) {
> - discardPbeFile(sPbeFileName);
> + discardPbeFile(*sPbeFileName);
>   }
>   LOG_ER("Exiting (line:%u)", __LINE__);
>   exit(1);
> @@ -3112,7 +3121,7 @@ SaAisErrorT getCcbOutcomeFromPbe(void* d
>   void fsyncPbeJournalFile()
>   {
>   int fd=(-1);
> - std::string globalJournalFilename(sPbeFileName);
> + std::string globalJournalFilename(*sPbeFileName);
>   globalJournalFilename.append("-journal");
>   fd = open(globalJournalFilename.c_str(), O_RDWR);
>   if(fd != (-1)) {
> diff --git a/src/imm/immpbed/immpbe_daemon.cc 
> b/src/imm/immpbed/immpbe_daemon.cc
> --- a/src/imm/immpbed/immpbe_daemon.cc
> +++ b/src/imm/immpbed/immpbe_daemon.cc
> @@ -2287,6 +2287,8 @@ void pbeDaemon(SaImmHandleT immHandle, v
>   continue;
>   
>   LOG_ER("poll failed - %s", strerror(errno));
> + pbeRepositoryClose(sDbHandle);
> + sDbHandle = NULL;
>   break;
>   }
>   

Re: [devel] [PATCH 0 of 1] Review Request for imm: Fix problems with removing coordinator role when cluster goes headless [#2296] v2

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2017/02/13 09:30 AM, Hung Nguyen wrote:
> Summary: imm: Fix problems with removing coordinator role when cluster goes 
> headless [#2296]
> Review request for Trac Ticket(s): 2296
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.0, 5.1, 5.2
> Development branch: 5.2
>
> 
> 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 39a796f4d47d39019a56dfe4c121417b6c88a0c7
> Author:   Hung Nguyen 
> Date: Fri, 10 Feb 2017 14:06:22 +0700
>
>   imm: Fix problems with removing coordinator role when cluster goes 
> headless
>   [#2296]
>
>   When SC comes back too fast, it will fail to change to SEVER_READY state
>   because immnd_proc_server() is not executed. This patch basically 
> reverts
>   the changes in immnd_proc_server() made by #1692 and moves them to
>   immnd_evt_proc_mds_evt().
>
>   Also, this patch hanldes the case when D2ND_SYNC_START is received but 
> sync
>   process isn't forked yet. That case was not handled in the patch for 
> #1692.
>
>
> Complete diffstat:
> --
>   src/imm/immnd/immnd_evt.c  |  35 ---
>   src/imm/immnd/immnd_proc.c |  22 ++
>   2 files changed, 34 insertions(+), 23 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: [devel] [PATCH 1 of 1] smf: admin owner err_exist on parallel procedures [#2288]

[Neelakanta Reddy]

Hi Rafael,

Reviewed and tested the patch.
Ack.

minor comments inline.

On 2017/02/06 08:27 PM, Rafael Odzakow wrote:
>   src/smf/smfd/SmfImmOperation.cc |  22 +-
>   src/smf/smfd/SmfUpgradeStep.cc  |  23 +--
>   2 files changed, 42 insertions(+), 3 deletions(-)
>
>
> Create a campaign containing several single step procedures that install
> several bundles. If the procedures are on the same saSmfExecLevel the campaign
> will sometimes fail because of conflicting admin owner on IMM object.
>
> trace message:
> SmfImmCreateOperation::execute:saImmOmAdminOwnerSet failed SA_AIS_ERR_EXIST
>
> diff --git a/src/smf/smfd/SmfImmOperation.cc b/src/smf/smfd/SmfImmOperation.cc
> --- a/src/smf/smfd/SmfImmOperation.cc
> +++ b/src/smf/smfd/SmfImmOperation.cc
> @@ -34,6 +34,7 @@
>   #include "imm/saf/saImm.h"
>   #include "base/saf_error.h"
>   #include "base/osaf_extended_name.h"
> +#include "base/osaf_time.h"
>   #include "smf/smfd/smfd_long_dn.h"
>   
>   /* 
> @@ -440,7 +441,26 @@ SmfImmCreateOperation::execute(SmfRollba
>   const SaNameT *objectNames[2];
>   objectNames[0] = 
>   objectNames[1] = NULL;
> - result = immutil_saImmOmAdminOwnerSet(m_immOwnerHandle, 
> objectNames, SA_IMM_ONE);
> +
> +// We are taking admin owner on the parent DN of this object.
> +// This can be conflicting with other threads which also want
> +// to create objects. Specifically SmfUpgradeStep takes admin
> +// owner when creating node groups. Retry if object has admin
> +// owner already.
> +int timeout_try_cnt = 6;
> +while (timeout_try_cnt > 0) {
> +TRACE("%s: calling adminOwnerSet", __FUNCTION__);
> +result = 
> immutil_saImmOmAdminOwnerSet(m_immOwnerHandle,
> +  objectNames,
> +  SA_IMM_ONE);
> +if (result != SA_AIS_ERR_EXIST)
> +break;
> +
> +timeout_try_cnt--;
> +TRACE("%s: adminOwnerSet returned SA_AIS_ERR_EXIST, 
> " +
The "+" at end of the line needs to be removed

> +  "sleep 1 second and retry", __FUNCTION__);
> +osaf_nanosleep();
> +}
>   if (result != SA_AIS_OK) {
>   
> TRACE("SmfImmCreateOperation::execute:saImmOmAdminOwnerSet failed %s\n", 
> saf_error(result));
>   TRACE_LEAVE();
> diff --git a/src/smf/smfd/SmfUpgradeStep.cc b/src/smf/smfd/SmfUpgradeStep.cc
> --- a/src/smf/smfd/SmfUpgradeStep.cc
> +++ b/src/smf/smfd/SmfUpgradeStep.cc
> @@ -3172,8 +3172,27 @@ bool SmfAdminOperation::becomeAdminOwner
>   SaNameT nodeGroupParentDn;
>   saAisNameLend(m_nodeGroupParentDn.c_str(), );
>   const SaNameT *objectNames[2] = {, NULL};
> - SaAisErrorT ais_rc = immutil_saImmOmAdminOwnerSet(m_ownerHandle,
> - objectNames, SA_IMM_SUBTREE);
> +
> +// We are taking admin owner on the parent DN of this object. This 
> can
> +// be conflicting with other threads which also want to create 
> objects.
> +// Specifically SmfImmOperation takes admin owner when creating IMM
> +// objects. Retry if object has admin owner already.
> +int timeout_try_cnt = 6;
> +SaAisErrorT ais_rc = SA_AIS_OK;
> +while (timeout_try_cnt > 0) {
> +TRACE("%s: calling adminOwnerSet", __FUNCTION__);
> +ais_rc = immutil_saImmOmAdminOwnerSet(m_ownerHandle,
> +  objectNames,
> +  SA_IMM_SUBTREE);
> +if (ais_rc != SA_AIS_ERR_EXIST)
> +break;
> +
> +timeout_try_cnt--;
> +TRACE("%s: adminOwnerSet returned SA_AIS_ERR_EXIST, " +
The "+" at end of the line needs to be removed

/Neel.
> +  "sleep 1 second and retry", __FUNCTION__);
> +osaf_nanosleep();
> +}
> +
>   bool rc = true;
>   if (ais_rc != SA_AIS_OK) {
>   LOG_NO("%s: saImmOmAdminOwnerSet owner name '%s' Fail '%s'",


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

Re: [devel] FW: `make rpm` giving error

[Neelakanta Reddy]

Hi ,

Used the attached patch, to compile on gcc 4.9.

/Neel.

On 2017/01/31 06:09 PM, Hans Nordeback wrote:
Hi Mahesh,  I can compile with or without this patch in my 
environment, can you check if the attached patch solves your build 
problems.


/Regards Hans


On 01/31/2017 01:34 PM, Hans Nordebäck wrote:


-Original Message-
From: Hans Nordebäck [mailto:hans.nordeb...@ericsson.com]
Sent: den 31 januari 2017 12:59
To: A V Mahesh ; Chani Srivastava 
; Anders Widell 


Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] `make rpm` giving error

Hi Mahesh, please ignore the patch, it should only include 
 where the PRI macros are used, I noticed that the patch 
includes it in too many places. /Regards HansN


-Original Message-
From: Hans Nordebäck
Sent: den 31 januari 2017 12:44
To: A V Mahesh ; Chani Srivastava 
; Anders Widell 

Cc: opensaf-devel@lists.sourceforge.net; Hans Nordebäck 


Subject: Re: [devel] `make rpm` giving error

Hi Mahesh,

I have built with gcc 4.8, 5.5 and 6.3 without any problem using 
Ubuntu 14. What environment are you using?


Anyhow, the required header files should be explicitly included in 
each required source file, I enclose a patch that explicitly includes


cinttypes, (not fully complete though), can you verify if it works?

/Regards HansN


On 01/31/2017 11:40 AM, A V Mahesh wrote:

Hi Hans N,


On 1/31/2017 3:58 PM, A V Mahesh wrote:

Hi Hans N,

This same issue exist with all following file , is their any common
location we  can include this

  ?

vi src/amf/amfd/mds.cc
vi src/imm/agent/imma_mds.cc
vi src/amf/amfd/ndfsm.cc
vi src/amf/amfd/mds.cc
vi src/amf/amfd/sgproc.cc
vi src/amf/amfd/siass.cc
vi src/amf/amfd/util.cc
vi src/amf/amfnd/amfnd.cc

vi src/amf/amfnd/clc.cc
vi src/amf/amfnd/comp.cc
vi src/amf/amfnd/di.cc
vi src/amf/amfnd/mds.cc
vi src/amf/amfnd/proxy.cc
vi src/amf/amfnd/proxydb.cc
...

Most of them are related to LOG_ER() macro related .

-AVM

-AVM

On 1/31/2017 3:10 PM, Hans Nordebäck wrote:

Perhaps the  has to be changed to  in
mds_log.cc, (__STDC_FORMAT_MACROS). /Regards Hans

-Original Message-
From: Chani Srivastava [mailto:chani.srivast...@oracle.com]
Sent: den 31 januari 2017 10:21
To: opensaf-devel@lists.sourceforge.net
Subject: [devel] `make rpm` giving error

Hi,

While creating rpm from latest opensaf-staging, I am getting
following errors.
64-bit machine
GCC version : 6.1

src/mds/mds_log.cc: In static member function 'static bool
MdsLog::Init()':
src/mds/mds_log.cc:93:50: error: expected ')' before 'PRIu32'
   snprintf(pid_path, sizeof(pid_path), "/proc/%" PRIu32
"/cmdline", process_id);
^~
src/mds/mds_log.cc:93:79: error: spurious trailing '%' in format
[-Werror=format=]
   snprintf(pid_path, sizeof(pid_path), "/proc/%" PRIu32
"/cmdline", process_id); ^
src/mds/mds_log.cc:93:79: error: too many arguments for format
[-Werror=format-extra-args]
cc1plus: all warnings being treated as errors
make[3]: *** [src/mds/lib_libopensaf_core_la-mds_log.lo] Error 1
make[3]: Leaving directory
`/home/chani/Builds/opensaf_latest/rpms/BUILD/opensaf-5.2.M0'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/chani/Builds/opensaf_latest/rpms/BUILD/opensaf-5.2.M0'
make[1]: *** [all] Error 2
make[1]: Leaving directory
`/home/chani/Builds/opensaf_latest/rpms/BUILD/opensaf-5.2.M0'
error: Bad exit status from
/home/chani/Builds/opensaf_latest/rpms/tmp/rpm-tmp.96704 (%build)


RPM build errors:
Bad exit status from
/home/chani/Builds/opensaf_latest/rpms/tmp/rpm-tmp.96704 (%build)
make: *** [rpm] Error 1



-
-

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


-- 

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




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


diff --git a/src/amf/amfd/mds.cc 

Re: [devel] [PATCH 1 of 1] smf: retry the ccb modify operation when the ccb is aborted with resource abort [#2277]

[Neelakanta Reddy]

Hi Rafael,

comments inline.

On 2017/01/31 03:54 PM, Rafael Odzakow wrote:
>
>
> On 01/31/2017 05:54 AM, Neelakanta Reddy wrote:
>> Hi Rafael,
>>
>> Comments inline.
>>
>> On 2017/01/30 07:33 PM, Rafael Odzakow wrote:
>>> ACK, with comments after [rafael] tag
>>>
>> I will add the comments, while pushing.
>>> As an improvement after the retries the operation can fail the 
>>> campaign. Today we only move the problem over to the next campaign?
>>>
>> No, the first campaign will not fail and the campaign state will be 
>> moved to campaign completed.
>> But saAmfSUMaintenanceCampaign  is not cleared, when the next 
>> campaign is tried it will fail with the error.
> That is my point. Why would we want to move a problem over to the next 
> campaign? Is it not better to fail at the right time?
As per the campaign state model, there is no failed state once you 
commit the campaign. The only state once the campaign committed is 
"campaign completed".

Thanks,
Neel.

>>
>> The patch, retries the modification of saAmfSUMaintenanceCampaign, if 
>> the ccb operation is aborted because of resource abort.
>>
>> Thanks,
>> Neel.
>>>
>>> On 01/30/2017 02:25 PM, reddy.neelaka...@oracle.com wrote:
>>>> osaf/services/saf/smfsv/smfd/SmfImmOperation.cc |  21 
>>>> ++---
>>>>   osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc |  16 
>>>> ++--
>>>>   2 files changed, 32 insertions(+), 5 deletions(-)
>>>>
>>>>
>>>> When the campaign is commited, while modifying 
>>>> saAmfSUMaintenanceCampaign  flags, if any of the IMMND restarts or
>>>> new node joins the cluster, then the non-commited ccbs will be 
>>>> aborted.
>>>>
>>>> This is a rare case, when saAmfSUMaintenanceCampaign will fail due 
>>>> to IMMND sync, and and the next campaign will fails with
>>>> ER Failed to set maintenance state in step=safSmfStep=0001
>>>>
>>>> diff --git a/osaf/services/saf/smfsv/smfd/SmfImmOperation.cc 
>>>> b/osaf/services/saf/smfsv/smfd/SmfImmOperation.cc
>>>> --- a/osaf/services/saf/smfsv/smfd/SmfImmOperation.cc
>>>> +++ b/osaf/services/saf/smfsv/smfd/SmfImmOperation.cc
>>>> @@ -1033,11 +1033,26 @@ SmfImmModifyOperation::execute(SmfRollba
>>>>   //   objectName.length = (SaUint16T) objectLen;
>>>>   //   memcpy(objectName.value, object, objectLen);
>>>>   +const SaStringT * errStrings = NULL;
>>>>   result = immutil_saImmOmCcbObjectModify_2(m_ccbHandle, 
>>>> , (const SaImmAttrModificationT_2 **)
>>>> -  m_immAttrMods);
>>>> -if (result != SA_AIS_OK) {
>>>> +m_immAttrMods);
>>>> +if (result != SA_AIS_OK && result == 
>>>> SA_AIS_ERR_FAILED_OPERATION) {
>>>> +result = saImmOmCcbGetErrorStrings(m_ccbHandle, );
>>>> +if (errStrings){
>>>> +TRACE("Received error string is %s", errStrings[0]);
>>>> +char * type = NULL;
>>>> +type = strstr(errStrings[0], "IMM: Resource abort: ");
>>>> +if(type != NULL) {
>>>> +TRACE("SA_AIS_ERR_FAILED_OPERATION is modified to 
>>>> SA_AIS_ERR_TRY_AGAIN because of ccb resourse abort" );
>>>> +result = SA_AIS_ERR_TRY_AGAIN;
>>>> +TRACE_LEAVE();
>>>> +return result;
>>>> +}
>>>> +}
>>>> +}
>>>> +if (result != SA_AIS_OK){
>>>>   LOG_NO("SmfImmModifyOperation::execute, 
>>>> saImmOmCcbObjectModify failed %s", saf_error(result));
>>>> -TRACE_LEAVE();
>>>> +TRACE_LEAVE();
>>>>   return result;
>>>>   }
>>>>   diff --git a/osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc 
>>>> b/osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc
>>>> --- a/osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc
>>>> +++ b/osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc
>>>> @@ -1063,6 +1063,7 @@ SmfUpgradeCampaign::resetMaintenanceStat
>>>>   std::list < std::string > objectList;
>>>>   SmfImmUtils immUtil;
>>>>   (void)immUtil.getChildren("", objectList, SA_IMM_SUBTREE

Re: [devel] [PATCH 1 of 1] smf: retry the ccb modify operation when the ccb is aborted with resource abort [#2277]

[Neelakanta Reddy]

Hi Rafael,

Comments inline.

On 2017/01/30 07:33 PM, Rafael Odzakow wrote:
> ACK, with comments after [rafael] tag
>
I will add the comments, while pushing.
> As an improvement after the retries the operation can fail the 
> campaign. Today we only move the problem over to the next campaign?
>
No, the first campaign will not fail and the campaign state will be 
moved to campaign completed.
But saAmfSUMaintenanceCampaign  is not cleared, when the next campaign 
is tried it will fail with the error.

The patch, retries the modification of saAmfSUMaintenanceCampaign, if 
the ccb operation is aborted because of resource abort.

Thanks,
Neel.
>
> On 01/30/2017 02:25 PM, reddy.neelaka...@oracle.com wrote:
>> osaf/services/saf/smfsv/smfd/SmfImmOperation.cc|  21 
>> ++---
>>   osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc |  16 
>> ++--
>>   2 files changed, 32 insertions(+), 5 deletions(-)
>>
>>
>> When the campaign is commited, while modifying 
>> saAmfSUMaintenanceCampaign  flags, if any of the IMMND restarts or
>> new node joins the cluster, then the non-commited ccbs will be aborted.
>>
>> This is a rare case, when saAmfSUMaintenanceCampaign will fail due to 
>> IMMND sync, and and the next campaign will fails with
>> ER Failed to set maintenance state in step=safSmfStep=0001
>>
>> diff --git a/osaf/services/saf/smfsv/smfd/SmfImmOperation.cc 
>> b/osaf/services/saf/smfsv/smfd/SmfImmOperation.cc
>> --- a/osaf/services/saf/smfsv/smfd/SmfImmOperation.cc
>> +++ b/osaf/services/saf/smfsv/smfd/SmfImmOperation.cc
>> @@ -1033,11 +1033,26 @@ SmfImmModifyOperation::execute(SmfRollba
>>   //   objectName.length = (SaUint16T) objectLen;
>>   //   memcpy(objectName.value, object, objectLen);
>>   +const SaStringT * errStrings = NULL;
>>   result = immutil_saImmOmCcbObjectModify_2(m_ccbHandle, 
>> , (const SaImmAttrModificationT_2 **)
>> -  m_immAttrMods);
>> -if (result != SA_AIS_OK) {
>> +m_immAttrMods);
>> +if (result != SA_AIS_OK && result == SA_AIS_ERR_FAILED_OPERATION) {
>> +result = saImmOmCcbGetErrorStrings(m_ccbHandle, );
>> +if (errStrings){
>> +TRACE("Received error string is %s", errStrings[0]);
>> +char * type = NULL;
>> +type = strstr(errStrings[0], "IMM: Resource abort: ");
>> +if(type != NULL) {
>> +TRACE("SA_AIS_ERR_FAILED_OPERATION is modified to 
>> SA_AIS_ERR_TRY_AGAIN because of ccb resourse abort" );
>> +result = SA_AIS_ERR_TRY_AGAIN;
>> +TRACE_LEAVE();
>> +return result;
>> +}
>> +}
>> +}
>> +if (result != SA_AIS_OK){
>>   LOG_NO("SmfImmModifyOperation::execute, 
>> saImmOmCcbObjectModify failed %s", saf_error(result));
>> -TRACE_LEAVE();
>> +TRACE_LEAVE();
>>   return result;
>>   }
>>   diff --git a/osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc 
>> b/osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc
>> --- a/osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc
>> +++ b/osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc
>> @@ -1063,6 +1063,7 @@ SmfUpgradeCampaign::resetMaintenanceStat
>>   std::list < std::string > objectList;
>>   SmfImmUtils immUtil;
>>   (void)immUtil.getChildren("", objectList, SA_IMM_SUBTREE, 
>> "SaAmfSU");
>> +SaAisErrorT rc = SA_AIS_OK;
>> //Reset saAmfSUMaintenanceCampaign for all found SUs
>>   const std::string campDn = 
>> SmfCampaignThread::instance()->campaign()->getDn();
>> @@ -1093,9 +1094,20 @@ SmfUpgradeCampaign::resetMaintenanceStat
>>   }
>>   }
>>   -if (immUtil.doImmOperations(operations) != SA_AIS_OK) {
>> -LOG_NO("SmfUpgradeStep::setMaintenanceState(), fails 
>> to reset all saAmfSUMaintenanceCampaign attr");
>> +const uint32_t MAX_NO_RETRIES = 2;
>> +uint32_t retry_cnt = 0;
>> +while (++retry_cnt <= MAX_NO_RETRIES) {
>> +rc = immUtil.doImmOperations(operations);
> [rafael] whitespace above
>> +if (rc != SA_AIS_OK && rc == SA_AIS_ERR_TRY_AGAIN) {
>> +/* TRY_AGAIN is returned only when ccb is aborted
> [rafael] whitespace above
>> +   with Resource abort in error string. Resurce abort in
>> +   error string is checked presently for modify 
>> operation */
> [rafael] no strict rule but I never use this comment style over 
> multiple lines. Maybe try:
> /*
> *
> */
> or
> //
> //
> //
>> +continue;
>> +}
>>   }
>> +if (rc != SA_AIS_OK){
>> +LOG_NO("SmfUpgradeStep::setMaintenanceState(), fails to 
>> reset all saAmfSUMaintenanceCampaign attr");
>> +}
>> //Delete the created SmfImmModifyOperation instances
>>   std::list < SmfImmOperation * > ::iterator operIter;
>


--
Check out the vibrant 

Re: [devel] [PATCH 0 of 1] Review Request for imm: Add missing checks for SaStringT attributes with ATTR_DN flag [#2270]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

README.SASTRINGT_API has information of allowing SA_IMM_ATTR_NO_DANGLING 
with SaStringT.
The same has to be replicated in README.NO_DANGLING.

/Neel.

On 2017/01/23 01:24 PM, Hung Nguyen wrote:
> Summary: imm: Add missing checks for SaStringT attributes with ATTR_DN flag 
> [#2270]
> Review request for Trac Ticket(s): 2270
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.0, 5.1, 5.2
> Development branch: 5.2
>
> 
> 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 d5a580a0c1b2d7ce1e0f91feb4e3021b4c416731
> Author:   Hung Nguyen 
> Date: Mon, 23 Jan 2017 14:52:21 +0700
>
>   imm: Add missing checks for SaStringT attributes with ATTR_DN flag 
> [#2270]
>
>   ImmModel::notCompatibleAtt() Check for dangling values when adding
>   NO_DANGLING flag to SaStringDN attributes.
>
>   ImmModel::ccbObjectModify() Check for SaStringDN attributes that have 
> long
>   DN values before disabling long DN (setting longDnsAllowed to 0).
>
>   ImmModel::rtObjectCreate() When long DN is disabled, don't allow 
> creating
>   runtime objects with SaStringDN attributes that have long DN value.
>
>   ImmModel::rtObjectUpdate() When long DN is disabled, don't allow setting
>   long DN value to SaStringDN attributes.
>
>
> Complete diffstat:
> --
>   src/imm/immnd/ImmModel.cc |  94 
> --
>   1 files changed, 52 insertions(+), 42 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that 

Re: [devel] [PATCH 0 of 1] Review Request for imm: Fix the mismatch when resetting sLastContinuationId [#2272]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2017/01/19 04:49 PM, Hung Nguyen wrote:
> Summary: imm: Fix the mismatch when resetting sLastContinuationId [#2272]
> Review request for Trac Ticket(s): 2272
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.0, 5.1, 5.2
> Development branch: 5.2
>
> 
> 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 d9e87a7b96bb0e2142bafb31032a5d47a43c2f0b
> Author:   Hung Nguyen 
> Date: Thu, 19 Jan 2017 18:12:52 +0700
>
>   imm: Fix the mismatch when resetting sLastContinuationId [#2272]
>
>   The mismatch only happens in ::ccbObjectCreate(), ::ccbObjectModify(),
>   ::deleteObject(). The changes in other functions are to make sure that 
> we
>   handle sLastContinuationId the same way in the whole IMM Model code.
>   sLastContinuationId will be increased (and reset if needed) before we 
> use
>   it.
>
>
> Complete diffstat:
> --
>   src/imm/immnd/ImmModel.cc |  58 
> --
>   1 files changed, 32 insertions(+), 26 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 0 of 1] Review Request for imm: Remove unused variables from saImmOmClassCreate_2 [#2271]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2017/01/19 04:08 PM, Hung Nguyen wrote:
> Summary: imm: Remove unused variables from saImmOmClassCreate_2() [#2271]
> Review request for Trac Ticket(s): 2271
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.2
> Development branch: 5.2
>
> 
> 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 43276ece820633e155df5c105ae7fb82a34ab17c
> Author:   Hung Nguyen 
> Date: Thu, 19 Jan 2017 14:05:31 +0700
>
>   imm: Remove unused variables from saImmOmClassCreate_2() [#2271]
>
>   Remove unused variables from saImmOmClassCreate_2().
>
>
> Complete diffstat:
> --
>   src/imm/agent/imma_om_api.cc |  147 
> +--
>   1 files changed, 69 insertions(+), 78 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 1 of 1] imm: Add imm_common to LIBADD list of libSaImmOi [#2273]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch, Ack.

/Neel.

On 2017/01/19 11:54 AM, Hung Nguyen wrote:
>   src/imm/Makefile.am |  1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
>
>
> Add imm_common to LIBADD list of libSaImmOi.
>
> diff --git a/src/imm/Makefile.am b/src/imm/Makefile.am
> --- a/src/imm/Makefile.am
> +++ b/src/imm/Makefile.am
> @@ -106,6 +106,7 @@ lib_libSaImmOi_la_LDFLAGS += \
>   -version-number 0:3:0
>   
>   lib_libSaImmOi_la_LIBADD = \
> + lib/libimm_common.la \
>   lib/libais.la \
>   lib/libopensaf_core.la
>   


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

Re: [devel] [PATCH 1 of 1] smf: failed one-step upgrade between opensaf versions [#2226]

[Neelakanta Reddy]

Hi Rafael,

Reviewed and tested the patch.
Ack.

/Neel.

On 2017/01/05 07:40 PM, Rafael Odzakow wrote:
>   src/smf/smfd/SmfExecControlHdl.cc |  20 
>   1 files changed, 16 insertions(+), 4 deletions(-)
>
>
> diff --git a/src/smf/smfd/SmfExecControlHdl.cc 
> b/src/smf/smfd/SmfExecControlHdl.cc
> --- a/src/smf/smfd/SmfExecControlHdl.cc
> +++ b/src/smf/smfd/SmfExecControlHdl.cc
> @@ -188,12 +188,24 @@ bool SmfExecControlObjHandler::smfProtec
>   bool SmfExecControlObjHandler::getValuesFromImmCopy() {
> bool errinfo = true;
>   
> -  TRACE_ENTER();
> -if (readExecControlObject(c_openSafSmfExecControl_copy) == false) {
> -  LOG_NO("%s readExecControlObject(c_openSafSmfExecControl_copy) Fail",
> - __FUNCTION__);
> +  std::string copydn = c_openSafSmfExecControl_copy;
> +  SaImmAttrValuesT_2 **attributes;
> +  if (!p_immutil_object->getObject(copydn, )) {
> +// We do not have a copy so create it. This can happen when upgrading 
> from
> +// an earlier version of SMF. SMF will only read the copy when it has 
> been
> +// restarted.
> +LOG_NO("No copy existing for execControl, read execControl and create 
> it");
> +if (!install()) {
> errinfo = false;
>   }
> +  }
> +
> +  TRACE_ENTER();
> +  if (readExecControlObject(c_openSafSmfExecControl_copy) == false) {
> +LOG_NO("%s readExecControlObject(c_openSafSmfExecControl_copy) Fail",
> +   __FUNCTION__);
> +errinfo = false;
> +  }
>   
> TRACE_LEAVE();
> return errinfo;


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

Re: [devel] [PATCH 1 of 1] imm: return TRY_AGAIN when RepositoryInit mode is chaged to file, during the CCB PBE di^Cble processing [#2229] V2

[Neelakanta Reddy]

Hi Hung,

update the comment, while pushing.

Thanks,
Neel.

On 2017/01/04 01:38 PM, Hung Nguyen wrote:
> Hi Neel,
>
> Reviewed and tested the patch.
> Ack with a minor comment:
>
> This testcase failed when pbe is enabled.
> root@SC-1:~# immoitest 4 6
>
> Suite 4: Configuration Objects Implementer
> error: in src/imm/apitest/implementer/test_SaImmOiCcb.c at 160: 
> SA_AIS_ERR_FAILED_OPERATION (21), expected SA_AIS_OK (1) - exiting
>
>
>
> In immnd_evt_proc_ccb_compl_rsp(), it should be 
> 'evt->info.ccbUpcallRsp.ccbId' instead of 'evt->info.ccbId'
>
> if(cb->mPbeDisableCcbId == evt->info.ccbId){
>   TRACE(" Disable of PBE is sent to PBE for ACK, in ccb:%u",  
> evt->info.ccbId);
>   cb->mPbeDisableCritical = true;
> }
>
> BR,
> Hung Nguyen - DEK Technologies
>
> 
> From: Neelakanta reddyreddy.neelaka...@oracle.com
> Sent: Friday, December 30, 2016 2:02PM
> To: Hung Nguyen, Zoran Milinkovic
>  hung.d.ngu...@dektech.com.au,zoran.milinko...@ericsson.com
> Cc: Opensaf-devel
>  opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] imm: return TRY_AGAIN when RepositoryInit mode is 
> chaged to file, during the CCB PBE di^Cble processing [#2229] V2
>
>
>   osaf/services/saf/immsv/immnd/ImmModel.cc |  29 
> -
>   osaf/services/saf/immsv/immnd/ImmModel.hh |   6 --
>   osaf/services/saf/immsv/immnd/immnd_cb.h  |   3 +++
>   osaf/services/saf/immsv/immnd/immnd_evt.c |  23 +++
>   4 files changed, 54 insertions(+), 7 deletions(-)
>
>
> TRY_AGAIN will be returned to the ccbApply when the saImmRepositoryInit is 
> changed from
> SA_IMM_KEEP_REPOSITORY to SA_IMM_INIT_FROM_FILE. The duration of the 
> TRY_AGAIN is from
> the time ccb upcall is sent to PBE to receiving ACK from the PBE for the 
> repository change CCB
>
> diff --git a/osaf/services/saf/immsv/immnd/ImmModel.cc 
> b/osaf/services/saf/immsv/immnd/ImmModel.cc
> --- a/osaf/services/saf/immsv/immnd/ImmModel.cc
> +++ b/osaf/services/saf/immsv/immnd/ImmModel.cc
> @@ -962,14 +962,19 @@ immModel_ccbObjectModify(IMMND_CB *cb,
>   {
>   std::string objectName;
>   bool pbeFile = (cb->mPbeFile != NULL);
> +bool changeRim = false;
>   SaAisErrorT err = ImmModel::instance(>immModel)->
>   ccbObjectModify(req, implConn, implNodeId, continuationId,
> -pbeConn, pbeNodeId, objectName, hasLongDns, pbeFile);
> +pbeConn, pbeNodeId, objectName, hasLongDns, pbeFile, );
>   
>   if(err == SA_AIS_OK) {
>   osaf_extended_name_alloc(objectName.c_str(), objName);
>   }
>   
> +if (err == SA_AIS_OK && changeRim){
> +cb->mPbeDisableCcbId = req->ccbId;
> + TRACE("The mPbeDisableCcbId is set to ccbid:%u", cb->mPbeDisableCcbId);
> +}
>   return err;
>   }
>   
> @@ -1361,6 +1366,12 @@ immModel_ccbAbort(IMMND_CB *cb,
>   unsigned int ix=0;
>   
>   bool aborted = ImmModel::instance(>immModel)->ccbAbort(ccbId, cv, 
> cl, nodeId, pbeNodeId);
> +
> +if ( aborted && (cb->mPbeDisableCcbId == ccbId)){
> +TRACE("PbeDisableCcbId %u has been aborted", ccbId);
> +cb->mPbeDisableCcbId = 0;
> +cb->mPbeDisableCritical = false;
> +}
>   
>   *arrSize = (SaUint32T) cv.size();
>   if(*arrSize) {
> @@ -1530,7 +1541,7 @@ immModel_ccbWaitForCompletedAck(IMMND_CB
>   SaUint32T* pbeCtn)
>   {
>   return ImmModel::instance(>immModel)->
> -ccbWaitForCompletedAck(ccbId, err, pbeConn, pbeNodeId, pbeId, 
> pbeCtn);
> +ccbWaitForCompletedAck(ccbId, err, pbeConn, pbeNodeId, pbeId, 
> pbeCtn, cb->mPbeDisableCritical);
>   }
>   
>   bool
> @@ -8860,7 +8871,8 @@ ImmModel::ccbObjectModify(const ImmsvOmC
>   unsigned int* pbeNodeIdPtr,
>   std::string& objectName,
>   bool* hasLongDns,
> -bool pbeFile)
> +bool pbeFile,
> +bool * changeRim)
>   {
>   TRACE_ENTER();
>   osafassert(hasLongDns);
> @@ -9342,6 +9354,7 @@ ImmModel::ccbObjectModify(const ImmsvOmC
>   }
>   
>   if (modifiedRim) {
> +SaImmRepositoryInitModeT oldRim = 
> getRepositoryInitMode();
>   SaImmRepositoryInitModeT newRim = 
> (SaImmRepositoryInitModeT) attrValue->getValue_int();
>   if((newRim != SA_IMM_INIT_FROM_FILE) && (newRim != 
> SA_IMM_KEEP_REPOSITORY)) {
>   TRACE_7("ERR_BAD_OPERATION: attr '%s' in IMM object 
> %s can not have value %u",
> @@ -9352,6 +9365,11 @@ ImmModel::ccbObjectModify(const ImmsvOmC
>   err = SA_AIS_ERR_BAD_OPERATION;
>   break;
>   }
> +
> +if((oldRim == SA_IMM_KEEP_REPOSITORY) && (newRim == 
> SA_IMM_INIT_FROM_FILE)){
> + LOG_NO("Request for rim change is arrived in ccb%u", 
> ccbId);
> +* changeRim = true;
> +}
>  

Re: [devel] [PATCH 1 of 1] imm: return TRY_AGAIN when RepositoryInit mode is chaged to file, during the CCB PBE disable processing [#2229]

[Neelakanta Reddy]

Hi Hung,

Comments inline.

On 2016/12/28 01:01 PM, Hung Nguyen wrote:
> Hi Neel,
>
> Please find my comments inline.
>
> BR,
> Hung Nguyen - DEK Technologies
>
> 
> From: Neelakanta reddyreddy.neelaka...@oracle.com
> Sent: Thursday, December 22, 2016 4:44PM
> To: Zoran Milinkovic, Hung Nguyen
>  zoran.milinko...@ericsson.com,hung.d.ngu...@dektech.com.au
> Cc: Opensaf-devel
>  opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] imm: return TRY_AGAIN when RepositoryInit mode is 
> chaged to file, during the CCB PBE disable processing [#2229]
>
>
>   osaf/services/saf/immsv/immnd/ImmModel.cc |  22 --
>   osaf/services/saf/immsv/immnd/ImmModel.hh |   3 ++-
>   osaf/services/saf/immsv/immnd/immnd_cb.h  |   3 +++
>   osaf/services/saf/immsv/immnd/immnd_evt.c |  24 
>   4 files changed, 49 insertions(+), 3 deletions(-)
>
>
> TRY_AGAIN will be returned to the ccbApply when the saImmRepositoryInit is 
> changed from
> SA_IMM_KEEP_REPOSITORY to SA_IMM_INIT_FROM_FILE. The duration of the 
> TRY_AGAIN is from
> the time ccb upcall is sent to PBE to receiving ACK from the PBE for the 
> repository change CCB.
>
> diff --git a/osaf/services/saf/immsv/immnd/ImmModel.cc 
> b/osaf/services/saf/immsv/immnd/ImmModel.cc
> --- a/osaf/services/saf/immsv/immnd/ImmModel.cc
> +++ b/osaf/services/saf/immsv/immnd/ImmModel.cc
> @@ -962,14 +962,19 @@ immModel_ccbObjectModify(IMMND_CB *cb,
>   {
>   std::string objectName;
>   bool pbeFile = (cb->mPbeFile != NULL);
> +bool changeRim = false;
>   SaAisErrorT err = ImmModel::instance(>immModel)->
>   ccbObjectModify(req, implConn, implNodeId, continuationId,
> -pbeConn, pbeNodeId, objectName, hasLongDns, pbeFile);
> +pbeConn, pbeNodeId, objectName, hasLongDns, pbeFile, );
>   
>   if(err == SA_AIS_OK) {
>   osaf_extended_name_alloc(objectName.c_str(), objName);
>   }
>   
> +if (err == SA_AIS_OK && changeRim){
> +cb->mPbeDisableCcbId = req->ccbId;
> + TRACE("The mPbeDisableCcbId is set to ccbid:%u", cb->mPbeDisableCcbId);
> +}
>   return err;
>   }
>   
> @@ -1361,6 +1366,12 @@ immModel_ccbAbort(IMMND_CB *cb,
>   unsigned int ix=0;
>   
>   bool aborted = ImmModel::instance(>immModel)->ccbAbort(ccbId, cv, 
> cl, nodeId, pbeNodeId);
> +
> +if ( aborted && (cb->mPbeDisableCcbId == ccbId)){
> +TRACE("PbeDisableCcbId %u has been aborted", ccbId);
> +cb->mPbeDisableCcbId = 0;
> +cb->mPbeDisableCritical = false;
> +}
>   
>   *arrSize = (SaUint32T) cv.size();
>   if(*arrSize) {
> @@ -8860,7 +8871,8 @@ ImmModel::ccbObjectModify(const ImmsvOmC
>   unsigned int* pbeNodeIdPtr,
>   std::string& objectName,
>   bool* hasLongDns,
> -bool pbeFile)
> +bool pbeFile,
> +bool * changeRim)
>   {
>   TRACE_ENTER();
>   osafassert(hasLongDns);
> @@ -9342,6 +9354,7 @@ ImmModel::ccbObjectModify(const ImmsvOmC
>   }
>   
>   if (modifiedRim) {
> +SaImmRepositoryInitModeT oldRim = 
> getRepositoryInitMode();
>   SaImmRepositoryInitModeT newRim = 
> (SaImmRepositoryInitModeT) attrValue->getValue_int();
>   if((newRim != SA_IMM_INIT_FROM_FILE) && (newRim != 
> SA_IMM_KEEP_REPOSITORY)) {
>   TRACE_7("ERR_BAD_OPERATION: attr '%s' in IMM object 
> %s can not have value %u",
> @@ -9352,6 +9365,11 @@ ImmModel::ccbObjectModify(const ImmsvOmC
>   err = SA_AIS_ERR_BAD_OPERATION;
>   break;
>   }
> +
> +if((oldRim == SA_IMM_KEEP_REPOSITORY) && (newRim == 
> SA_IMM_INIT_FROM_FILE)){
> + LOG_NO("Request for rim change is arrived in ccb%u", 
> ccbId);
> +* changeRim = true;
> +}
>   }
>   
>   
> diff --git a/osaf/services/saf/immsv/immnd/ImmModel.hh 
> b/osaf/services/saf/immsv/immnd/ImmModel.hh
> --- a/osaf/services/saf/immsv/immnd/ImmModel.hh
> +++ b/osaf/services/saf/immsv/immnd/ImmModel.hh
> @@ -254,7 +254,8 @@ public:
>   unsigned int* pbeNodeId,
>   std::string& objectName,
>   bool* hasLongDns,
> -bool pbeFile);
> +bool pbeFile,
> +bool* changeRim);
>   
>   SaAisErrorT ccbObjectDelete(
>   const ImmsvOmCcbObjectDelete* req,
> diff --git a/osaf/services/saf/immsv/immnd/immnd_cb.h 
> b/osaf/services/saf/immsv/immnd/immnd_cb.h
> --- a/osaf/services/saf/immsv/immnd/immnd_cb.h
> +++ b/osaf/services/saf/immsv/immnd/immnd_cb.h
> @@ -129,6 +129,9 @@ 

Re: [devel] [PATCH 0 of 1] Review Request for smf: builds on ubuntu 16.04 cause segmentation fault [#2242]

[Neelakanta Reddy]

Hi Rafael,

Reviewed the patch.
Ack.

/Neel.

On 2016/12/22 06:55 PM, Rafael Odzakow wrote:
> Summary: smf: builds on ubuntu 16.04 cause segmentation fault [#2242]
> Review request for Trac Ticket(s): #2242
> Peer Reviewer(s): lennart, reddy
> Pull request to: <>
> Affected branch(es): <>
> Development branch: <>
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesn
>   OpenSAF servicesy
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>   <>
>
> changeset 5e43097d3c02ab6df503917640dffefda6722ad3
> Author:   Rafael Odzakow 
> Date: Thu, 22 Dec 2016 14:22:07 +0100
>
>   smf: builds on ubuntu 16.04 cause segmentation fault [#2242]
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |  6 +-
>   1 files changed, 5 insertions(+), 1 deletions(-)
>
>
> Testing Commands:
> -
>   running a campaign with empty activation unit list with step modifications
>
>
> Testing, Expected Results:
> --
>   <>
>
>
> Conditions of Submission:
> -
>   <>
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


--
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/intel
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 0 of 1] Review Request for imm: Remove use of SaBoolT from message type [#2225]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2016/12/20 01:06 PM, Hung Nguyen wrote:
> Summary: imm: Remove use of SaBoolT from message type [#2225]
> Review request for Trac Ticket(s): 2225
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.2
> Development branch: 5.2
>
> 
> 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 3669eff495ef0fed0d22273c63c7a3d66cf58b94
> Author:   Hung Nguyen 
> Date: Tue, 20 Dec 2016 13:18:41 +0700
>
>   imm: Remove use of SaBoolT from message type [#2225]
>
>   SaBoolT can be replaced by bool in message type because that doesn't 
> change
>   the result of ncs_encode/ncs_decode.
>
>
> Complete diffstat:
> --
>   osaf/libs/agents/saf/imma/imma_om_api.cc |  4 ++--
>   osaf/libs/common/immsv/include/immsv_evt_model.h |  6 +++---
>   osaf/services/saf/immsv/immnd/ImmModel.cc|  4 ++--
>   3 files changed, 7 insertions(+), 7 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


--
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/intel
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 0 of 3] Review Request for imm: Remove use of SaBoolT [#2225]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

patch 3 of 3 is same as "[PATCH 0 of 1] Review Request for imm: Remove 
use of SaBoolT [#2225]"

/Neel.

On 2016/12/14 02:16 PM, Hung Nguyen wrote:
> Summary: imm: Remove use of SaBoolT [#2225]
> Review request for Trac Ticket(s): 2225
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.2
> Development branch: 5.2
>
> 
> 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 03a077ba8a5acf92d5d068f4db327722dd213af2
> Author:   Hung Nguyen 
> Date: Tue, 13 Dec 2016 09:40:26 +0700
>
>   imm: Remove use of SaBoolT from library [#2225]
>
>   imm: Remove use of SaBoolT from library.
>
> changeset 3df2eb6a3a690f6336537baddd36285e34ef6240
> Author:   Hung Nguyen 
> Date: Tue, 13 Dec 2016 13:13:18 +0700
>
>   imm: Remove use of SaBoolT from IMMND [#2225]
>
>   imm: Remove use of SaBoolT from IMMND.
>
> changeset 421945c108b10cfabda659cb5412fc1d482ee371
> Author:   Hung Nguyen 
> Date: Tue, 13 Dec 2016 13:40:11 +0700
>
>   imm: Remove use of SaBoolT from IMM tools and tests [#2225]
>
>   imm: Remove use of SaBoolT from IMM tools and tests.
>
>
> Complete diffstat:
> --
>   osaf/libs/agents/saf/imma/imma_oi_api.cc|6 +-
>   osaf/libs/agents/saf/imma/imma_om_api.cc|   48 
> ++--
>   osaf/services/saf/immsv/immnd/ImmModel.cc   |  182 
> ---
>   osaf/services/saf/immsv/immnd/ImmModel.hh   |4 +-
>   osaf/services/saf/immsv/immnd/ImmSearchOp.cc|6 +-
>   osaf/services/saf/immsv/immnd/ImmSearchOp.hh|2 +-
>   osaf/services/saf/immsv/immnd/immnd_evt.c   |  486 
> 
>   osaf/services/saf/immsv/immnd/immnd_init.h  |   78 
> ++--
>   osaf/services/saf/immsv/immnd/immnd_main.c  |4 +-
>   osaf/services/saf/immsv/immnd/immnd_proc.c  |   74 
> ++--
>   osaf/tools/safimm/immcfg/imm_cfg.c  |   12 +-
>   osaf/tools/safimm/src/immutil.c |4 +-
>   samples/immsv/immutils/immutil.c|4 +-
>   tests/immsv/implementer/test_SaImmOiAdminOperation.c|   30 
>   tests/immsv/implementer/test_SaImmOiRtAttrUpdateCallbackT.c |4 +-
>   15 files changed, 467 insertions(+), 477 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission 

Re: [devel] [PATCH 0 of 3] Review Request for imm: Improve the iteration in ImmModel [#2224]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2016/12/13 08:58 AM, Hung Nguyen wrote:
> Summary: imm: Improve the iteration in ImmModel [#2224]
> Review request for Trac Ticket(s): 2224
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.2
> Development branch: 5.2
>
> 
> 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 5bc30a78e98beb7d491f4f3e878cd070e608d54c
> Author:   Hung Nguyen 
> Date: Mon, 12 Dec 2016 18:02:56 +0700
>
>   imm: Use return from map::erase() to avoid resetting iterator to begin
>   [#2224]
>
>   Use return from map::erase() to avoid resetting iterator to begin.
>
> changeset 1b2efe4ef31a35037a68f21d628fc61e4f6d4b5d
> Author:   Hung Nguyen 
> Date: Mon, 12 Dec 2016 18:57:55 +0700
>
>   imm: Don't reset iterator to begin when clearing a map [#2224]
>
>   When removing all elements from a map, iterate through the map to free 
> each
>   element and then use clear() to clear the map.
>
> changeset ae81673cb4757caaedaad902e8f29cf417ae82c4
> Author:   Hung Nguyen 
> Date: Mon, 12 Dec 2016 19:02:07 +0700
>
>   imm: Use erase(key_type) to remove all elements with specific key 
> [#2224]
>
>   Use erase(key_type) to remove all elements with specific key.
>
>
> Complete diffstat:
> --
>   osaf/services/saf/immsv/immnd/ImmModel.cc |  101 
> +++--
>   1 files changed, 51 insertions(+), 50 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  

Re: [devel] [PATCH 0 of 1] Review Request for smf: ER messages when handling smfnd node up [#1872]

[Neelakanta Reddy]

Hi, Lennart,

Reviewed the patch.
Ack.

/Neel.

On 2016/12/14 03:33 PM, Lennart Lund wrote:
> Summary: smf: ER messages when handling smfnd node up
> Review request for Trac Ticket(s): #1872
> Peer Reviewer(s): rafael.odza...@ericsson.com, reddy.neelaka...@oracle.com
> Pull request to: <>
> Affected branch(es): 5.0, 5.1, default
> Development branch: <>
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>   <>
>
> changeset c2c382f2d7ca0c5532408c73f1262ff9378ebdf1
> Author:   Lennart Lund 
> Date: Wed, 14 Dec 2016 10:49:00 +0100
>
>   smf: ER messages when handling smfnd node up [#1872]
>
>   Change the message severity from ER to WA
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/smfd_smfnd.c |  8 
>   1 files changed, 4 insertions(+), 4 deletions(-)
>
>
> Testing Commands:
> -
>   <>
>
>
> Testing, Expected Results:
> --
>   <>
>
>
> Conditions of Submission:
> -
> One week or ack from reviewers
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 0 of 1] Review Request for imm: move IMM error string prefixes to header file [#2198]

[Neelakanta Reddy]

Hi zoran,

Reviewed and tested the patch.
Ack.

/Neel.

On 2016/12/08 07:03 PM, Zoran Milinkovic wrote:
> Summary: imm: move IMM error string prefixes to header file [#2198]
> Review request for Trac Ticket(s): 2198
> Peer Reviewer(s): Hung, Neelakanta
> Pull request to: Zoran
> Affected branch(es): default(5.3)
> Development branch: default(5.3)
>
> 
> 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 482be4eb534d858a1df19228bd131b83d0e89cd3
> Author:   Zoran Milinkovic 
> Date: Thu, 08 Dec 2016 14:30:43 +0100
>
>   imm: move IMM error string prefixes to header file [#2198]
>
>   Move IMM error string prefixes to immnd_cb.h header file.
>
>
> Complete diffstat:
> --
>   osaf/services/saf/immsv/immnd/ImmModel.cc |  4 
>   osaf/services/saf/immsv/immnd/immnd_cb.h  |  4 
>   osaf/services/saf/immsv/immnd/immnd_evt.c |  4 
>   3 files changed, 4 insertions(+), 8 deletions(-)
>
>
> Testing Commands:
> -
>
>
> Testing, Expected Results:
> --
>
>
> Conditions of Submission:
> -
> Ack from Neelakanta and Hung
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 0 of 1] Review Request for smf:Allow optimization at node level forAddRemove in mergeStepIntoSingle[#2214]

[Neelakanta Reddy]

Hi Rafael,

Can you please comment on the below points:

1.   forAddRemove Optimization of node must be present in both 
activation and deactivation. (The published patch does not check if the 
node is present in both AU & DU).

2. The published patch must also include for Su/Comp and optimize if 
present in both AU & DU.


Thanks,
Neel.

On 2016/12/02 06:46 PM, Neelakanta Reddy wrote:
> Hi Tai,
>
> forAddRemove  we can have the following cases:
> 1.  only  deactivationUnit
> 2. only  activationUnit
> 3. both
>
> For case 1 and 2 we can not optimize for node/Su/Comp.
> For case 3 we can optimize for node/Su/comp.
>
> I think the published patch needs to be corrected.
> i.e if node/SU/Comp is present in both activation and deactivation then
> only optimize, otherwise do not optimize.
>
> Thanks,
> Neel.
>
>
>
> On 2016/12/02 05:44 PM, Tai Chi DINH wrote:
>> Hi Neel,
>>
>> I think we also need to remove any duplication under SU level and
>> Component Level also.
>> Example we have the original campaign that have:
>> - Rolling on SCs
>> - ForModify on SU1, SU2 that are hosted on PLs
>> - ForAddRemoved on SU1, SU2.
>>
>> Which this patch, the result campaign will have AU/DU on
>> SCs/SU1/SU2/SU1/SU2.
>> Which means we have redundant/unnecessary lock/unlock of SU1/SU2 (it's
>> enough to just lock/unlock them only once).
>>
>> How do you think?
>>
>> /Tai
>> Quoting Neelakanta Reddy <reddy.neelaka...@oracle.com
>> <mailto:reddy.neelaka...@oracle.com>>:
>>
>>> Hi All,
>>>
>>> Here the defect no is #2209 not #2214
>>>
>>> Thanks,
>>> Neel.
>>>
>>> On 2016/12/02 04:22 PM, reddy.neelaka...@oracle.com
>>> <mailto:reddy.neelaka...@oracle.com> wrote:
>>>> Summary: smf:Allow optimization at node level forAddRemove in
>>>> mergeStepIntoSingle[#2214]
>>>> Review request for Trac Ticket(s): 2214
>>>> Peer Reviewer(s): Rafael, Lennart, tai
>>>> Affected branch(es): 5.0.x, 5.1.x, 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 2becbe07a7f92d70f928e23dcd6b0a6576c8e22a
>>>> Author:Neelakanta Reddy <reddy.neelaka...@oracle.com
>>>> <mailto:reddy.neelaka...@oracle.com>>
>>>> Date:Fri, 02 Dec 2016 16:16:33 +0530
>>>>
>>>>  smf:Allow optimization at node level forAddRemove in
>>>>  mergeStepIntoSingle[#2214]
>>>>
>>>>
>>>> Complete diffstat:
>>>> --
>>>> osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |  40
>>>> +++-
>>>> 1 files changed, 39 insertions(+), 1 deletions(-)
>>>>
>>>>
>>>> Testing Commands:
>>>> -
>>>> campaign must contain rolling and singlestep upgrade with AU/SU node
>>>> level
>>>>
>>>> Testing, Expected Results:
>>>> --
>>>> Campaign should not fail
>>>>
>>>> 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

Re: [devel] [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in completed callback[#1956] V4

[Neelakanta Reddy]

Hi Zoran,

The saImmOmAccessorGet_o3 is called by the privateOMhandle initialized 
by saImmOiAugmentCcbInitialize with version A.2.17.
This is hard-coded in the saImmOiAugmentCcbInitialize.

Thanks,
Neel

On 2016/12/06 08:38 PM, Zoran Milinkovic wrote:
> Hi Neelakanta,
>
> saImmOmAccessorGet_o3() in immsv_om_augment_ccb_get_admo_name() will not work 
> for IMM handles initialized with versions earlier than A.2.15.
> You can add SaNameT variable in the function, set object in the variable, and 
> call saImmOmAccessorGet_2().
> Or you can make it in an easy way and not-so-recommended and call directly 
> accessor_get_common() with 'bUseString' set to 'false'. It's all internal API 
> use, so it's ok to use accessor_get_common() from my point of view.
>
> Thanks,
> Zoran
>
>
> -Original Message-
> From: reddy.neelaka...@oracle.com [mailto:reddy.neelaka...@oracle.com]
> Sent: den 6 december 2016 12:11
> To: Hung Duc Nguyen ; Zoran Milinkovic 
> 
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in 
> completed callback[#1956] V4
>
>   osaf/libs/agents/saf/imma/imma_cb.h |5 +
>   osaf/libs/agents/saf/imma/imma_db.c |   41 +
>   osaf/libs/agents/saf/imma/imma_oi_api.c |  102 ++-
>   osaf/libs/agents/saf/imma/imma_om_api.c |   11 +-
>   osaf/libs/agents/saf/imma/imma_proc.c   |  134 
> ++-
>   5 files changed, 172 insertions(+), 121 deletions(-)
>
>
> diff --git a/osaf/libs/agents/saf/imma/imma_cb.h 
> b/osaf/libs/agents/saf/imma/imma_cb.h
> --- a/osaf/libs/agents/saf/imma/imma_cb.h
> +++ b/osaf/libs/agents/saf/imma/imma_cb.h
> @@ -36,6 +36,10 @@ struct imma_oi_ccb_record {
>   struct imma_callback_info* ccbCallback;
>   SaImmHandleT privateAugOmHandle;
>   SaImmAdminOwnerHandleT privateAoHandle;
> + SaStringT object;/* The  Object string from the modify/delete ccb 
> operation. The object is used to obtain
> + adminOwner when saImmOiAugmentCcbInitialize is called 
> in completed-callback*/
> + SaStringT adminOwner; /* adminowner of the ccb id, assigned at 
> ccb-create-callback. The adminOwner used in
> +saImmOiAugmentCcbInitialize is called in 
> completed-callback*/
>   };
>   
>   typedef struct imma_client_node {
> @@ -197,6 +201,7 @@ int imma_oi_ccb_record_set_critical(IMMA
>   int imma_oi_ccb_record_terminate(IMMA_CLIENT_NODE *cl_node, SaImmOiCcbIdT 
> ccbId);
>   int imma_oi_ccb_record_abort(IMMA_CLIENT_NODE *cl_node, SaImmOiCcbIdT 
> ccbId);
>   int imma_oi_ccb_record_exists(IMMA_CLIENT_NODE *cl_node, SaImmOiCcbIdT 
> ccbId);
> +struct imma_oi_ccb_record * imma_oi_ccb_record_find(IMMA_CLIENT_NODE 
> *cl_node, SaImmOiCcbIdT ccbId);
>   int imma_oi_ccb_record_set_error(IMMA_CLIENT_NODE *cl_node, SaImmOiCcbIdT 
> ccbId, const SaStringT errorString);
>   SaStringT imma_oi_ccb_record_get_error(IMMA_CLIENT_NODE *cl_node, 
> SaImmOiCcbIdT ccbId);
>   void imma_oi_ccb_allow_error_string(IMMA_CLIENT_NODE *cl_node, 
> SaImmOiCcbIdT ccbId);
> diff --git a/osaf/libs/agents/saf/imma/imma_db.c 
> b/osaf/libs/agents/saf/imma/imma_db.c
> --- a/osaf/libs/agents/saf/imma/imma_db.c
> +++ b/osaf/libs/agents/saf/imma/imma_db.c
> @@ -24,6 +24,8 @@
>   
> */
>   
>   #include "imma.h"
> +#include "osaf_extended_name.h"
> +
>   
> /
> Name  : imma_client_tree_init
> Description   : This routine is used to initialize the client tree
> @@ -273,6 +275,15 @@ int imma_oi_ccb_record_delete(IMMA_CLIEN
>   to_delete->mCcbErrorString = NULL;
>   }
>   
> + if(to_delete->object){
> + free(to_delete->object);
> + to_delete->object = NULL;
> + }
> + if(to_delete->adminOwner){
> + free(to_delete->adminOwner);
> + to_delete->adminOwner = NULL;
> + }
> +
>   free(to_delete);
>   TRACE_LEAVE();
>   return 1;
> @@ -541,6 +552,9 @@ int imma_oi_ccb_record_note_callback(IMM
>*/
>   
>   int rs = 0;
> + const SaImmAttrNameT admoNameAttr = SA_IMM_ATTR_ADMIN_OWNER_NAME;
> + SaImmAttrValuesT_2 *attrVal = NULL;
> +
>   struct imma_oi_ccb_record *tmp = imma_oi_ccb_record_find(cl_node, 
> ccbId);
>   
>   if(tmp && !(tmp->isAborted)) {
> @@ -553,7 +567,34 @@ int imma_oi_ccb_record_note_callback(IMM
>   rs = 1;
>   }
>   }
> + if(callback){
> + if(callback->type == IMMA_CALLBACK_OI_CCB_CREATE && 
> !(tmp->adminOwner)) {   
> + SaImmAttrValuesT_2 **attributes = NULL;
> + attributes = (SaImmAttrValuesT_2 **) 
> 

Re: [devel] [PATCH 0 of 5] Review Request for imm: Compile the IMM library using the C++ compiler [#2142]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2016/11/03 04:30 PM, Hung Nguyen wrote:
> Summary: imm: Compile the IMM library using the C++ compiler [#2142]
> Review request for Trac Ticket(s): 2142
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.2
> Development branch: 5.2
>
> 
> 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 2a00f46102c46d227d6050fe8991d88eb86b903f
> Author:   Hung Nguyen 
> Date: Wed, 02 Nov 2016 11:23:40 +0700
>
>   imm: Compile the IMM library using the C++ compiler [#2142]
>
>   Compile the IMM library using the C++ compiler.
>
> changeset 48f7f2ba7b9d4d091d0e230fc1d55e724e8fc628
> Author:   Hung Nguyen 
> Date: Wed, 02 Nov 2016 11:23:40 +0700
>
>   imm: Fix "crosses initialization" errors [#2142]
>
>   Fix "crosses initialization" errors.
>
> changeset 4539872836e8771009194bb02881e21d9ad68135
> Author:   Hung Nguyen 
> Date: Wed, 02 Nov 2016 11:23:40 +0700
>
>   imm: Fix "invalid conversion" errors. [#2142]
>
>   Fix "invalid conversion" errors.
>
> changeset 4feae1a1f865c5e1ca1db15d49dc0c53a5e60588
> Author:   Hung Nguyen 
> Date: Wed, 02 Nov 2016 11:23:40 +0700
>
>   imm: Fix "comparison between signed and unsigned integer" errors [#2142]
>
>   Fix "comparison between signed and unsigned integer" errors.
>
> changeset 32c3655fbd2baa8b9e87dbba6c6834135d573d97
> Author:   Hung Nguyen 
> Date: Wed, 02 Nov 2016 11:23:40 +0700
>
>   imm: Fix linkage errors [#2142]
>
>   Fix linkage errors.
>
>
> Complete diffstat:
> --
>   osaf/libs/agents/saf/imma/Makefile.am   |   24 -
>   osaf/libs/agents/saf/imma/imma_cb.h |2 +-
>   osaf/libs/agents/saf/imma/imma_db.c |   12 --
>   osaf/libs/agents/saf/imma/imma_init.c   |5 +---
>   osaf/libs/agents/saf/imma/imma_mds.c|4 +-
>   osaf/libs/agents/saf/imma/imma_oi_api.c |   43 
> +++---
>   osaf/libs/agents/saf/imma/imma_om_api.c |  169 
> 
>   osaf/libs/agents/saf/imma/imma_proc.c   |  106 
> ---
>   osaf/libs/agents/saf/imma/imma_proc.h   |8 +++---
>   osaf/libs/core/mds/include/mds_dl_api.h |9 
>   osaf/libs/saf/libSaImm/Makefile.am  |4 +-
>   osaf/libs/saf/libSaImm/libSaImmOm.map   |   14 +++-
>   12 files changed, 206 insertions(+), 194 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These 

Re: [devel] [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in completed callback[#1956] V3

[Neelakanta Reddy]

Hi Hung,

Thanks for your comments.
will re-publish the patch, shortly.

/Neel.

On 2016/12/06 02:21 PM, Hung Nguyen wrote:
> Hi Neel,
>
> Tested the patch and had coredump from pbe and appliers.
>
> 1. In case of applier, imma_proc_ccbaug_setup() return immediately
> if(cl_node->isApplier) {return;}
> so callback->attrValsForCreateUc is not populated.
>
> 2. When creating runtime object, the callback type is 
> IMMA_CALLBACK_PBE_PRT_OBJ_CREATE.
> It goes to the default of the switch statement in imma_proc_ccbaug_setup().
> In imma_oi_ccb_record_note_callback(), with NULL callback, 
> callback->attrValsForCreateUc is not populated.
>
> Attached is the coredump backtrace.
>
>
> BR,
> Hung Nguyen - DEK Technologies
>
> 
> From: Neelakanta reddyreddy.neelaka...@oracle.com
> Sent: Monday, December 05, 2016 5:38PM
> To: Zoran Milinkovic, Hung Nguyen
>  zoran.milinko...@ericsson.com,hung.d.ngu...@dektech.com.au
> Cc: Opensaf-devel
>  opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in 
> completed callback[#1956] V3
>
>
>   osaf/libs/agents/saf/imma/imma_cb.h |5 +
>   osaf/libs/agents/saf/imma/imma_db.c |  107 
> 
>   osaf/libs/agents/saf/imma/imma_oi_api.c |  102 
> +-
>   osaf/libs/agents/saf/imma/imma_om_api.c |   11 +-
>   osaf/libs/agents/saf/imma/imma_proc.c   |   64 +-
>   5 files changed, 168 insertions(+), 121 deletions(-)
>
>
> diff --git a/osaf/libs/agents/saf/imma/imma_cb.h 
> b/osaf/libs/agents/saf/imma/imma_cb.h
> --- a/osaf/libs/agents/saf/imma/imma_cb.h
> +++ b/osaf/libs/agents/saf/imma/imma_cb.h
> @@ -36,6 +36,10 @@ struct imma_oi_ccb_record {
>   struct imma_callback_info* ccbCallback;
>   SaImmHandleT privateAugOmHandle;
>   SaImmAdminOwnerHandleT privateAoHandle;
> + SaStringT object;/* The  Object string from the modify/delete ccb 
> operation. The object is used to obtain
> + adminOwner when saImmOiAugmentCcbInitialize is called 
> in completed-callback*/
> + SaStringT adminOwner; /* adminowner of the ccb id, assigned at 
> ccb-create-callback. The adminOwner used in
> +saImmOiAugmentCcbInitialize is called in 
> completed-callback*/
>   };
>   
>   typedef struct imma_client_node {
> @@ -197,6 +201,7 @@ int imma_oi_ccb_record_set_critical(IMMA
>   int imma_oi_ccb_record_terminate(IMMA_CLIENT_NODE *cl_node, SaImmOiCcbIdT 
> ccbId);
>   int imma_oi_ccb_record_abort(IMMA_CLIENT_NODE *cl_node, SaImmOiCcbIdT 
> ccbId);
>   int imma_oi_ccb_record_exists(IMMA_CLIENT_NODE *cl_node, SaImmOiCcbIdT 
> ccbId);
> +struct imma_oi_ccb_record * imma_oi_ccb_record_find(IMMA_CLIENT_NODE 
> *cl_node, SaImmOiCcbIdT ccbId);
>   int imma_oi_ccb_record_set_error(IMMA_CLIENT_NODE *cl_node, SaImmOiCcbIdT 
> ccbId, const SaStringT errorString);
>   SaStringT imma_oi_ccb_record_get_error(IMMA_CLIENT_NODE *cl_node, 
> SaImmOiCcbIdT ccbId);
>   void imma_oi_ccb_allow_error_string(IMMA_CLIENT_NODE *cl_node, 
> SaImmOiCcbIdT ccbId);
> diff --git a/osaf/libs/agents/saf/imma/imma_db.c 
> b/osaf/libs/agents/saf/imma/imma_db.c
> --- a/osaf/libs/agents/saf/imma/imma_db.c
> +++ b/osaf/libs/agents/saf/imma/imma_db.c
> @@ -24,6 +24,8 @@
>   
> */
>   
>   #include "imma.h"
> +#include "osaf_extended_name.h"
> +
>   
> /
> Name  : imma_client_tree_init
> Description   : This routine is used to initialize the client tree
> @@ -273,6 +275,15 @@ int imma_oi_ccb_record_delete(IMMA_CLIEN
>   to_delete->mCcbErrorString = NULL;
>   }
>   
> + if(to_delete->object){
> + free(to_delete->object);
> + to_delete->object = NULL;
> + }
> + if(to_delete->adminOwner){
> + free(to_delete->adminOwner);
> + to_delete->adminOwner = NULL;
> + }
> +
>   free(to_delete);
>   TRACE_LEAVE();
>   return 1;
> @@ -541,6 +552,11 @@ int imma_oi_ccb_record_note_callback(IMM
>*/
>   
>   int rs = 0;
> + const SaImmAttrNameT admoNameAttr = SA_IMM_ATTR_ADMIN_OWNER_NAME;
> + SaImmAttrValuesT_2 **attr, **attributes = NULL;
> + SaImmAttrValuesT_2 *attrVal = NULL;
> + size_t attrDataSize = 0;
> +
>   struct imma_oi_ccb_record *tmp = imma_oi_ccb_record_find(cl_node, 
> ccbId);
>   
>   if(tmp && !(tmp->isAborted)) {
> @@ -553,7 +569,98 @@ int imma_oi_ccb_record_note_callback(IMM
>   rs = 1;
>   }
>   }
> + if(callback){
> + if(callback->type == IMMA_CALLBACK_OI_CCB_CREATE){
> + int noOfAttributes = 0;
>   
> +   

Re: [devel] [PATCH 0 of 1] Review Request for smf:Allow optimization at node level forAddRemove in mergeStepIntoSingle[#2214]

[Neelakanta Reddy]

Hi Lennart,

By mistakenly I included the name of #2214 instead of #2209 in the 
review request for #2209.

The review request/comments on the patch are referring to #2209 (not #2214).

Here we are talking about #2209 only(but the published patch has defect 
number #2214 ).

If you are still confused, please let me know I will re-publish #2209 
with correct defect number.

Thanks,
Neel.


On 2016/12/05 05:13 PM, Lennart Lund wrote:
>
> Hi,
>
> I am a little bit confused regarding the review of ticket #2209. I was 
> asked to prioritize reviewing of #2209 and I can see that the ticket 
> has status “review” but I cannot find any review request for this 
> ticket. However the patch sent for review for ticket #2214 seems to 
> contain the code Tai Dinh added as a comment in the #2209 ticket? Also 
> the #2214 ticket is in state “unassigned”. Can someone please clarify 
> what the problem is, what patch that solves it and which ticket we are 
> talking about. Also please fix so that ticket #2214 and #2209 gets the 
> correct state.
>
> Thanks
>
> Lennart
>
> *From:*Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
> *Sent:* den 2 december 2016 14:16
> *To:* Tai Chi Dinh <tai.d...@dektech.com.au>
> *Cc:* Lennart Lund <lennart.l...@ericsson.com>; Rafael Odzakow 
> <rafael.odza...@ericsson.com>; opensaf-devel@lists.sourceforge.net
> *Subject:* Re: [devel] [PATCH 0 of 1] Review Request for smf:Allow 
> optimization at node level forAddRemove in mergeStepIntoSingle[#2214]
>
> Hi Tai,
>
> forAddRemove  we can have the following cases:
> 1.  only  deactivationUnit
> 2. only  activationUnit
> 3. both
>
> For case 1 and 2 we can not optimize for node/Su/Comp.
> For case 3 we can optimize for node/Su/comp.
>
> I think the published patch needs to be corrected.
> i.e if node/SU/Comp is present in both activation and deactivation 
> then only optimize, otherwise do not optimize.
>
> Thanks,
> Neel.
>
>
> On 2016/12/02 05:44 PM, Tai Chi DINH wrote:
>
> Hi Neel,
>
> I think we also need to remove any duplication under SU level and
> Component Level also.
> Example we have the original campaign that have:
> - Rolling on SCs
> - ForModify on SU1, SU2 that are hosted on PLs
> - ForAddRemoved on SU1, SU2.
>
> Which this patch, the result campaign will have AU/DU on
> SCs/SU1/SU2/SU1/SU2.
> Which means we have redundant/unnecessary lock/unlock of SU1/SU2
> (it's enough to just lock/unlock them only once).
>
> How do you think?
>
> /Tai
> Quoting Neelakanta Reddy <reddy.neelaka...@oracle.com
> <mailto:reddy.neelaka...@oracle.com>>:
>
> Hi All,
>
> Here the defect no is #2209 not #2214
>
> Thanks,
> Neel.
>
> On 2016/12/02 04:22 PM, reddy.neelaka...@oracle.com
> <mailto:reddy.neelaka...@oracle.com> wrote:
>
> Summary: smf:Allow optimization at node level forAddRemove
> in mergeStepIntoSingle[#2214]
> Review request for Trac Ticket(s): 2214
> Peer Reviewer(s): Rafael, Lennart, tai
> Affected branch(es): 5.0.x, 5.1.x, 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 2becbe07a7f92d70f928e23dcd6b0a6576c8e22a
> Author:Neelakanta Reddy
> <reddy.neelaka...@oracle.com
> <mailto:reddy.neelaka...@oracle.com>>
> Date:Fri, 02 Dec 2016 16:16:33 +0530
>
> smf:Allow optimization at node level forAddRemove in
> mergeStepIntoSingle[#2214]
>
>
> Complete diffstat:
> --
> osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |  40
> +++-
> 1 files changed, 39 insertions(+), 1 deletions(-)
>
>
> Testing Commands:
> 

Re: [devel] [PATCH 0 of 1] Review Request for smf:Allow optimization at node level forAddRemove in mergeStepIntoSingle[#2214]

[Neelakanta Reddy]

Hi All,

Here the defect no is #2209 not #2214

Thanks,
Neel.

On 2016/12/02 04:22 PM, reddy.neelaka...@oracle.com wrote:
> Summary: smf:Allow optimization at node level forAddRemove in 
> mergeStepIntoSingle[#2214]
> Review request for Trac Ticket(s): 2214
> Peer Reviewer(s): Rafael, Lennart, tai
> Affected branch(es): 5.0.x, 5.1.x, 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 2becbe07a7f92d70f928e23dcd6b0a6576c8e22a
> Author:   Neelakanta Reddy <reddy.neelaka...@oracle.com>
> Date: Fri, 02 Dec 2016 16:16:33 +0530
>
>   smf:Allow optimization at node level forAddRemove in
>   mergeStepIntoSingle[#2214]
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |  40 
> +++-
>   1 files changed, 39 insertions(+), 1 deletions(-)
>
>
> Testing Commands:
> -
> campaign must contain rolling and singlestep upgrade with AU/SU node level
>
> Testing, Expected Results:
> --
> Campaign should not fail
>
> 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.
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.o

Re: [devel] [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in completed callback[#1956] V2

[Neelakanta Reddy]

Hi Hung,

comments inline.

On 2016/12/01 03:07 PM, Hung Nguyen wrote:
> Hi Neel,
>
> Besides Zoran's comment, I have 2 more comments inline.
>
> BR,
> Hung Nguyen - DEK Technologies
>
> 
> From: Neelakanta reddyreddy.neelaka...@oracle.com
> Sent: Wednesday, November 30, 2016 12:39PM
> To: Zoran Milinkovic, Hung Nguyen
>  zoran.milinko...@ericsson.com,hung.d.ngu...@dektech.com.au
> Cc: Opensaf-devel
>  opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in 
> completed callback[#1956] V2
>
>
>   osaf/libs/agents/saf/imma/imma_cb.h |   5 +
>   osaf/libs/agents/saf/imma/imma_db.c |  99 
> +
>   osaf/libs/agents/saf/imma/imma_oi_api.c |  60 +++
>   osaf/libs/agents/saf/imma/imma_proc.c   |  64 ++---
>   4 files changed, 133 insertions(+), 95 deletions(-)
>
>
> Two new variables objectName and adminOwnerName added to imma_oi_ccb_record. 
> For CCB create operation adminOwnerName will be added.
> For CCB delete/modify operation objectName will be added
>
> diff --git a/osaf/libs/agents/saf/imma/imma_cb.h 
> b/osaf/libs/agents/saf/imma/imma_cb.h
> --- a/osaf/libs/agents/saf/imma/imma_cb.h
> +++ b/osaf/libs/agents/saf/imma/imma_cb.h
> @@ -36,6 +36,10 @@ struct imma_oi_ccb_record {
>   struct imma_callback_info* ccbCallback;
>   SaImmHandleT privateAugOmHandle;
>   SaImmAdminOwnerHandleT privateAoHandle;
> + SaNameT objectName;/* The  Object name from the modif/delete ccb 
> operationi. The objectName is used to obtain
> + adminOnerName when saImmOiAugmentCcbInitialize is 
> called in completed-callback*/
> + SaNameT adminOwnerName; /* adminowner name of the ccb id, assigned at 
> ccb-create-callback.The adminOwnerName is used
> +saImmOiAugmentCcbInitialize is called in 
> completed-callback*/
>   };
>   
>   typedef struct imma_client_node {
> @@ -197,6 +201,7 @@ int imma_oi_ccb_record_set_critical(IMMA
>   int imma_oi_ccb_record_terminate(IMMA_CLIENT_NODE *cl_node, SaImmOiCcbIdT 
> ccbId);
>   int imma_oi_ccb_record_abort(IMMA_CLIENT_NODE *cl_node, SaImmOiCcbIdT 
> ccbId);
>   int imma_oi_ccb_record_exists(IMMA_CLIENT_NODE *cl_node, SaImmOiCcbIdT 
> ccbId);
> +struct imma_oi_ccb_record * imma_oi_ccb_record_find(IMMA_CLIENT_NODE 
> *cl_node, SaImmOiCcbIdT ccbId);
>   int imma_oi_ccb_record_set_error(IMMA_CLIENT_NODE *cl_node, SaImmOiCcbIdT 
> ccbId, const SaStringT errorString);
>   SaStringT imma_oi_ccb_record_get_error(IMMA_CLIENT_NODE *cl_node, 
> SaImmOiCcbIdT ccbId);
>   void imma_oi_ccb_allow_error_string(IMMA_CLIENT_NODE *cl_node, 
> SaImmOiCcbIdT ccbId);
> diff --git a/osaf/libs/agents/saf/imma/imma_db.c 
> b/osaf/libs/agents/saf/imma/imma_db.c
> --- a/osaf/libs/agents/saf/imma/imma_db.c
> +++ b/osaf/libs/agents/saf/imma/imma_db.c
> @@ -24,6 +24,8 @@
>   
> */
>   
>   #include "imma.h"
> +#include "osaf_extended_name.h"
> +
>   
> /
> Name  : imma_client_tree_init
> Description   : This routine is used to initialize the client tree
> @@ -273,6 +275,9 @@ int imma_oi_ccb_record_delete(IMMA_CLIEN
>   to_delete->mCcbErrorString = NULL;
>   }
>   
> + osaf_extended_name_free(&(to_delete->objectName));
> + osaf_extended_name_free(&(to_delete->adminOwnerName));
> +
>   free(to_delete);
>   TRACE_LEAVE();
>   return 1;
> @@ -541,6 +546,11 @@ int imma_oi_ccb_record_note_callback(IMM
>*/
>   
>   int rs = 0;
> + const SaImmAttrNameT admoNameAttr = SA_IMM_ATTR_ADMIN_OWNER_NAME;
> + SaImmAttrValuesT_2 **attr, **attributes = NULL;
> + SaImmAttrValuesT_2 *attrVal = NULL;
> + size_t attrDataSize = 0;
> +
>   struct imma_oi_ccb_record *tmp = imma_oi_ccb_record_find(cl_node, 
> ccbId);
>   
>   if(tmp && !(tmp->isAborted)) {
> @@ -553,7 +563,96 @@ int imma_oi_ccb_record_note_callback(IMM
>   rs = 1;
>   }
>   }
> + if(callback){
>   
> +
> + int noOfAttributes = 0;
> +
> + /* NOTE: The code below is practically a copy of the code
> +in immOm searchNext, for serving the attrValues structure.
> +This code should be factored out into some common function.
> +  */
> + IMMSV_ATTR_VALUES_LIST *p = callback->attrValues;
> + int i = 0;
> + while (p) {
> + ++noOfAttributes;
> + p = p->next;
> + }
> +
> + p = callback->attrValues;
> +
> +
> + if(cl_node->isImmA2fCbk) {
> + if(noOfAttributes) {
> + p = 

Re: [devel] [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in completed callback[#1956] V2

[Neelakanta Reddy]

Hi zoran,

Yes, the code needs to be corrected for IMMA_CALLBACK_OI_CCB_COMPLETED.

Thanks,
Neel.

On 2016/12/01 02:42 PM, Zoran Milinkovic wrote:
>
> Hi Hung,
>
> Then the code needs to be fixed, and objectName variable can remain in 
> the code.
>
> Otherwise I don’t see the purpose of the variable.
>
> Thanks,
>
> Zoran
>
> *From:*Hung Nguyen [mailto:hung.d.ngu...@dektech.com.au]
> *Sent:* den 1 december 2016 10:04
> *To:* Zoran Milinkovic <zoran.milinko...@ericsson.com>; Neelakanta 
> Reddy <reddy.neelaka...@oracle.com>
> *Cc:* opensaf-devel@lists.sourceforge.net
> *Subject:* Re: [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as 
> false in completed callback[#1956] V2
>
> Hi Zoran,
>   
> It's still needed, Neel just forgot to pass the 'object' param to 
> immsv_om_augment_ccb_get_admo_name() when it's IMMA_CALLBACK_OI_CCB_COMPLETED.
> 'cbi->name' is not set (not usable) when it's a CcbCompletedCallback and we 
> have to use 'object' param instead.
>   
> BR,
> Hung Nguyen - DEK Technologies
>
> 
> From: Zoran milinkoviczoran.milinko...@ericsson.com 
> <mailto:zoran.milinko...@ericsson.com>
> Sent: Thursday, December 01, 2016 3:53PM
> To: Neelakanta Reddy, Hung Nguyen
>  reddy.neelaka...@oracle.com 
> <mailto:reddy.neelaka...@oracle.com>,hung.d.ngu...@dektech.com.au 
> <mailto:hung.d.ngu...@dektech.com.au>
> Cc: Opensaf-devel
>  opensaf-devel@lists.sourceforge.net 
> <mailto:opensaf-devel@lists.sourceforge.net>
> Subject: RE: [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in 
> completed callback[#1956] V2
>   
> Hi Neelakanta,
>   
> I still don't see where you use the new objectName variable.
> The only place where the variable is used is:
>   
> +   if((cbi->type == IMMA_CALLBACK_OI_CCB_CREATE)|| 
> ((cbi->type == IMMA_CALLBACK_OI_CCB_COMPLETED) &&
> +   
> !osaf_is_extended_name_empty(&(ccb_oi_record->adminOwnerName{
> +   admName = ccb_oi_record->adminOwnerName;
> +   } else {
> +   rc = getAdmoName(privateOmHandle, cbi, 
> &(ccb_oi_record->objectName),);
> +   }
>   
> But, if you look at getAdmoName()  function, you will see that the third 
> parameter is not used in the function at all, and it implies that objectName 
> is not needed as well.
>   
> Thanks,
> Zoran
>   
> -Original Message-
> From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
> Sent: den 1 december 2016 05:56
> To: Zoran Milinkovic<zoran.milinko...@ericsson.com> 
> <mailto:zoran.milinko...@ericsson.com>; Hung Duc 
> Nguyen<hung.d.ngu...@dektech.com.au> <mailto:hung.d.ngu...@dektech.com.au>
> Cc:opensaf-devel@lists.sourceforge.net 
> <mailto:opensaf-devel@lists.sourceforge.net>
> Subject: Re: [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in 
> completed callback[#1956] V2
>   
> Hi Zoran,
>   
> comments inline.
>   
> On 2016/11/30 06:11 PM, Zoran Milinkovic wrote:
> 
> From: Zoran milinkoviczoran.milinko...@ericsson.com 
> <mailto:zoran.milinko...@ericsson.com>
> Sent: Thursday, December 01, 2016 3:53PM
> To: Neelakanta Reddy, Hung Nguyen
>  reddy.neelaka...@oracle.com 
> <mailto:reddy.neelaka...@oracle.com>,hung.d.ngu...@dektech.com.au 
> <mailto:hung.d.ngu...@dektech.com.au>
> Cc: Opensaf-devel
>  opensaf-devel@lists.sourceforge.net 
> <mailto:opensaf-devel@lists.sourceforge.net>
> Subject: RE: [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in 
> completed callback[#1956] V2
>   
>   
>
> Hi Neelakanta,
>
>   
>
> The new objectName variable is not used in the code.
>
> I think here you are referring to variable name.
> The variable name can be changed to object.
>
> I would rather like to see adminOwnerName as some sort of string type 
> than using SaNameT. This is not an issue in the patch, only the suggestion.
>
> The reason for this is to try to avoid using SaNameT type as much as 
> possible, and replace it with SaImmAdminOwnerNameT (or other sting type).
>
> SaStringT will be used for both object and adminOwnerName
>
> Find other comments inline
>
>   
>
> -Original Message-
>
> From:reddy.neelaka...@oracle.com <mailto:reddy.neelaka...@oracle.com>  
> [mailto:reddy.neelaka...@oracle.com]
>
> Sent:

Re: [devel] [PATCH 1 of 1] smf: Avoid unconditional sleep when calling adminoperation[#2211] V1

[Neelakanta Reddy]

Hi ,

will be pushing the patch if there are no further comments.
#2212 is opened to change SmfImmUtils AdminOperation the same way as 
Node group admin operation.

Thanks,
Neel.

On 2016/11/30 02:42 PM, Tai Dinh wrote:
> Thank Neel,
>
> ACK from me.
>
> /Tai
> -Original Message-
> From: reddy.neelaka...@oracle.com [mailto:reddy.neelaka...@oracle.com]
> Sent: Wednesday, November 30, 2016 3:47 PM
> To: lennart.l...@ericsson.com; rafael.odza...@ericsson.com;
> tai.d...@dektech.com.au
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] smf: Avoid unconditional sleep when calling
> adminoperation[#2211] V1
>
>   osaf/services/saf/smfsv/smfd/SmfUtils.cc |  26 +++---
>   1 files changed, 15 insertions(+), 11 deletions(-)
>
>
> diff --git a/osaf/services/saf/smfsv/smfd/SmfUtils.cc
> b/osaf/services/saf/smfsv/smfd/SmfUtils.cc
> --- a/osaf/services/saf/smfsv/smfd/SmfUtils.cc
> +++ b/osaf/services/saf/smfsv/smfd/SmfUtils.cc
> @@ -583,19 +583,23 @@ SmfImmUtils::callAdminOperation(const st
>   }
>   
>   /* Call the admin operation */
> - do {
> - TRACE("call immutil_saImmOmAdminOperationInvoke_2");
> + 
> + TRACE("call immutil_saImmOmAdminOperationInvoke_2");
> + rc = immutil_saImmOmAdminOperationInvoke_2(m_ownerHandle,
> , 0, i_operationId, i_params,
> + , i_timeout);
> + while ((rc == SA_AIS_OK) && (returnValue == SA_AIS_ERR_TRY_AGAIN) &&
> (retry > 0) ){
> + sleep(2);
>   rc = immutil_saImmOmAdminOperationInvoke_2(m_ownerHandle,
> , 0, i_operationId, i_params,
> -,
> i_timeout);
> - if (retry <= 0) {
> - LOG_NO("Fail to invoke admin operation, too many
> SA_AIS_ERR_TRY_AGAIN, giving up. dn=[%s], opId=[%u]",
> -i_dn.c_str(), i_operationId);
> - rc = SA_AIS_ERR_TRY_AGAIN;
> - goto done;
> - }
> - sleep(2);
> + , i_timeout);
>   retry--;
> - } while ((rc == SA_AIS_OK) && (returnValue ==
> SA_AIS_ERR_TRY_AGAIN));
> + }
> + 
> + if (retry <= 0) {
> + LOG_NO("Fail to invoke admin operation, too many
> SA_AIS_ERR_TRY_AGAIN, giving up. dn=[%s], opId=[%u]",
> + i_dn.c_str(), i_operationId);
> + rc = SA_AIS_ERR_TRY_AGAIN;
> + goto done;
> + }
>   
>   if ( rc != SA_AIS_OK) {
>   LOG_NO("Fail to invoke admin operation, rc=%s. dn=[%s],
> opId=[%u]",saf_error(rc), i_dn.c_str(), i_operationId);
>


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

Re: [devel] [PATCH 1 of 1] smf: Avoid uncditional sleep when calling adminoperation[#2211]

[Neelakanta Reddy]

Hi Lennart,

This defect is related to unconditional delay of 2 seconds.
will open another defect/enhancement  to fix Smfutil unpredictable 
timeout and use smfutil in nodegroups as well .

Thanks,
Neel.

On 2016/11/30 02:54 PM, Lennart Lund wrote:
> Hi Neel
>
> In handling of admin state of node groups there is a similar loop that from 
> the beginning was a copy of the loop in SmfUtils. I have changed this loop to 
> remove the incorrect 2 sec sleep and also fixed the unpredictable timeout 
> time for the loop. I was thinking that the loop in SmfUtils should be fixed 
> in the same way and also make it possible to use the SmfUtil admin operation 
> handling with node groups as well. What do you think about this?
>
> Thanks
> Lennart
>
>> -Original Message-
>> From: reddy.neelaka...@oracle.com [mailto:reddy.neelaka...@oracle.com]
>> Sent: den 30 november 2016 08:53
>> To: Lennart Lund ; Rafael Odzakow
>> ; Tai Chi Dinh 
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: [PATCH 1 of 1] smf: Avoid uncditional sleep when calling
>> adminoperation[#2211]
>>
>>   osaf/services/saf/smfsv/smfd/SmfUtils.cc |  26 +++---
>>   1 files changed, 15 insertions(+), 11 deletions(-)
>>
>>
>> diff --git a/osaf/services/saf/smfsv/smfd/SmfUtils.cc
>> b/osaf/services/saf/smfsv/smfd/SmfUtils.cc
>> --- a/osaf/services/saf/smfsv/smfd/SmfUtils.cc
>> +++ b/osaf/services/saf/smfsv/smfd/SmfUtils.cc
>> @@ -583,19 +583,23 @@ SmfImmUtils::callAdminOperation(const st
>>  }
>>
>>  /* Call the admin operation */
>> -do {
>> -TRACE("call immutil_saImmOmAdminOperationInvoke_2");
>> +
>> +TRACE("call immutil_saImmOmAdminOperationInvoke_2");
>> +rc = immutil_saImmOmAdminOperationInvoke_2(m_ownerHandle,
>> , 0, i_operationId, i_params,
>> +, i_timeout);
>> +while ((rc == SA_AIS_OK) && (returnValue ==
>> SA_AIS_ERR_TRY_AGAIN)){
>> +sleep(2);
>>  rc =
>> immutil_saImmOmAdminOperationInvoke_2(m_ownerHandle,
>> , 0, i_operationId, i_params,
>> -   ,
>> i_timeout);
>> -if (retry <= 0) {
>> -LOG_NO("Fail to invoke admin operation, too many
>> SA_AIS_ERR_TRY_AGAIN, giving up. dn=[%s], opId=[%u]",
>> -   i_dn.c_str(), i_operationId);
>> -rc = SA_AIS_ERR_TRY_AGAIN;
>> -goto done;
>> -}
>> -sleep(2);
>> +, i_timeout);
>>  retry--;
>> -} while ((rc == SA_AIS_OK) && (returnValue ==
>> SA_AIS_ERR_TRY_AGAIN));
>> +}
>> +
>> +if (retry <= 0) {
>> +LOG_NO("Fail to invoke admin operation, too many
>> SA_AIS_ERR_TRY_AGAIN, giving up. dn=[%s], opId=[%u]",
>> +i_dn.c_str(), i_operationId);
>> +rc = SA_AIS_ERR_TRY_AGAIN;
>> +goto done;
>> +}
>>
>>  if ( rc != SA_AIS_OK) {
>>  LOG_NO("Fail to invoke admin operation, rc=%s. dn=[%s],
>> opId=[%u]",saf_error(rc), i_dn.c_str(), i_operationId);


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

Re: [devel] [PATCH 1 of 1] smf: Avoid uncditional sleep when calling adminoperation[#2211]

[Neelakanta Reddy]

Hi Tai,

Yes, you are correct.
will add "retry > 0" and re-publish the patch.

Thanks,
Neel.

On 2016/11/30 01:43 PM, Tai Dinh wrote:
> Hi Neel,
>
> NACK with the patch.
> Need to add 'retry > 0'  as part of while loop condition.
>
> /Tai
> -Original Message-
> From: reddy.neelaka...@oracle.com [mailto:reddy.neelaka...@oracle.com]
> Sent: Wednesday, November 30, 2016 2:53 PM
> To: lennart.l...@ericsson.com; rafael.odza...@ericsson.com;
> tai.d...@dektech.com.au
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] smf: Avoid uncditional sleep when calling
> adminoperation[#2211]
>
>   osaf/services/saf/smfsv/smfd/SmfUtils.cc |  26 +++---
>   1 files changed, 15 insertions(+), 11 deletions(-)
>
>
> diff --git a/osaf/services/saf/smfsv/smfd/SmfUtils.cc
> b/osaf/services/saf/smfsv/smfd/SmfUtils.cc
> --- a/osaf/services/saf/smfsv/smfd/SmfUtils.cc
> +++ b/osaf/services/saf/smfsv/smfd/SmfUtils.cc
> @@ -583,19 +583,23 @@ SmfImmUtils::callAdminOperation(const st
>   }
>   
>   /* Call the admin operation */
> - do {
> - TRACE("call immutil_saImmOmAdminOperationInvoke_2");
> + 
> + TRACE("call immutil_saImmOmAdminOperationInvoke_2");
> + rc = immutil_saImmOmAdminOperationInvoke_2(m_ownerHandle,
> , 0, i_operationId, i_params,
> + , i_timeout);
> + while ((rc == SA_AIS_OK) && (returnValue == SA_AIS_ERR_TRY_AGAIN)){
> + sleep(2);
>   rc = immutil_saImmOmAdminOperationInvoke_2(m_ownerHandle,
> , 0, i_operationId, i_params,
> -,
> i_timeout);
> - if (retry <= 0) {
> - LOG_NO("Fail to invoke admin operation, too many
> SA_AIS_ERR_TRY_AGAIN, giving up. dn=[%s], opId=[%u]",
> -i_dn.c_str(), i_operationId);
> - rc = SA_AIS_ERR_TRY_AGAIN;
> - goto done;
> - }
> - sleep(2);
> + , i_timeout);
>   retry--;
> - } while ((rc == SA_AIS_OK) && (returnValue ==
> SA_AIS_ERR_TRY_AGAIN));
> + }
> + 
> + if (retry <= 0) {
> + LOG_NO("Fail to invoke admin operation, too many
> SA_AIS_ERR_TRY_AGAIN, giving up. dn=[%s], opId=[%u]",
> + i_dn.c_str(), i_operationId);
> + rc = SA_AIS_ERR_TRY_AGAIN;
> + goto done;
> + }
>   
>   if ( rc != SA_AIS_OK) {
>   LOG_NO("Fail to invoke admin operation, rc=%s. dn=[%s],
> opId=[%u]",saf_error(rc), i_dn.c_str(), i_operationId);
>


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

Re: [devel] [PATCH 0 of 1] Review Request for imm: Correct nodeId assertion in ImmModel::ccbAbort() [#2205]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2016/11/25 01:04 PM, Hung Nguyen wrote:
> Summary: imm: Correct nodeId assertion in ImmModel::ccbAbort() [#2205]
> Review request for Trac Ticket(s): 2205
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.0, 5.1, 5.2
> Development branch: 5.2
>
> 
> 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 41175372ec20475544059b3654130a68b1072bb5
> Author:   Hung Nguyen 
> Date: Fri, 25 Nov 2016 11:08:49 +0700
>
>   imm: Correct nodeId assertion in ImmModel::ccbAbort() [#2205]
>
>   Correct nodeId assertion in ImmModel::ccbAbort().
>
>
> Complete diffstat:
> --
>   osaf/services/saf/immsv/immnd/ImmModel.cc |  7 +--
>   1 files changed, 5 insertions(+), 2 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in completed callback[#1956]

[Neelakanta Reddy]

Hi Hung,

I over looked imma_oi_ccb_record, the idea was to avoid increasing 
library memory, if the apply/abort is not called.
I agree that it can be done from OI side also.
will re-publish the patch.

Thanks,
Neel.

On 2016/11/23 02:58 PM, Hung Nguyen wrote:
> Hi Neel,
>
> 'struct imma_oi_ccb_record' is already defined in imma_cb.h
> It's used to store information of a specific CCB.
>
> By using imma_oi_ccb_record to store admoName/ObjectName,
> we can avoid new message and also don't have to change anything in IMMND 
> server.
>
>
> BR,
> Hung Nguyen - DEK Technologies
>
> 
> From: Neelakanta reddyreddy.neelaka...@oracle.com
> Sent: Wednesday, November 23, 2016 3:56PM
> To: Hung Nguyen, Zoran Milinkovic
>  hung.d.ngu...@dektech.com.au,zoran.milinko...@ericsson.com
> Cc: Opensaf-devel
>  opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in 
> completed callback[#1956]
>
>
> Hi Hung,
>
> Multiple adminowners are allowed for each immhandle
> Multiple ccbhandles(IDs) allowed for each adminownerhandle
>
> If we need to store in the OI cb , then we have to book-keep ccbids 
> and there corresponding ccb operation object name
>
> Instead I chose to read from IMMND , as AccessorGet or new message 
> will have to get admin owner from IMMND.
>
> Thanks,
> Neel.
>
> On 2016/11/23 01:47 PM, Hung Nguyen wrote:
>> Hi Neel,
>>
>> I think we can fix this ticket without new message type.
>>
>> Before the CcbCompleted callback, the OI always gets one or more 
>> CcbCreate/Modify/Delete callbacks.
>> We can use those callbacks to get admo name.
>>
>> We add more members to 'struct imma_oi_ccb_record'
>> SaStringT firstObjectName;
>> SaStringT adminOwnerName;
>>
>>
>> CcbCreate callback:
>> We can get the admo name right away
>> by reading 'SaImmAttrAdminOwnerName' attribute from 
>> 'evt->info.objCreate.attrValues'
>> Then store the admo name in imma_oi_ccb_record.adminOwnerName.
>>
>>
>> CcbModify/Delete callback:
>> We can't get the admo name right away.
>> We have to store the object name in imma_oi_ccb_record.firstObjectName.
>> This only needs to be done once, no need to overwrite 'firstObjectName' in 
>> later callbacks.
>> We only need one object name of the CCB.
>>
>>
>> Now when we need to get admo name in CcbCompleted callback,
>> we have to fetch the imma_oi_ccb_record of that ccb.
>> If the ccb_record already has adminOwnerName, we can use it right away.
>> If the ccb_record only has firstObjectName, use saImmOmAccessorGet_2 to 
>> retrieve the admo name.
>>
>>
>> BR,
>> Hung Nguyen - DEK Technologies
>>
>> 
>> From: Neelakanta reddyreddy.neelaka...@oracle.com
>> Sent: Friday, November 18, 2016 9:54PM
>> To: Zoran Milinkovic, Hung Nguyen
>>  zoran.milinko...@ericsson.com,hung.d.ngu...@dektech.com.au
>> Cc: Opensaf-devel
>>  opensaf-devel@lists.sourceforge.net
>> Subject: [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in 
>> completed callback[#1956]
>>
>>
>>   osaf/libs/agents/saf/imma/imma_oi_api.c|  156 
>> +---
>>   osaf/libs/common/immsv/immsv_evt.c |   49 ++--
>>   osaf/libs/common/immsv/include/immsv_evt.h |2 +
>>   osaf/services/saf/immsv/immnd/ImmModel.cc  |   39 +++
>>   osaf/services/saf/immsv/immnd/ImmModel.hh  |3 +
>>   osaf/services/saf/immsv/immnd/immnd_evt.c  |   65 
>>   osaf/services/saf/immsv/immnd/immnd_init.h |3 +
>>   7 files changed, 284 insertions(+), 33 deletions(-)
>>
>>
>> with saImmOmCcbObjectRead, completed callback is also allowed to call 
>> saImmOiAugmentCcbInitialize.
>>   When ROF is false the augumentInit will get new adminowner with same name 
>> as old adminowner name with ROF as true.
>>
>> Since, object name is not set for completed callback, a new event from OI to 
>> IMMND is required to get adminownername from ccbID
>> The patch inroduces new event by sending ccbID and response of the event 
>> will be the adminname of the corresponding ccbId.
>>
>> diff --git a/osaf/libs/agents/saf/imma/imma_oi_api.c 
>> b/osaf/libs/agents/saf/imma/imma_oi_api.c
>> --- a/osaf/libs/agents/saf/imma/imma_oi_api.c
>> +++ b/osaf/libs/agents/saf/imma/imma_oi_api.c
>> @@ -3617,6 +3617,97 @@ getAdmoName(SaImmHandleT privateOmHandle
>>   }
>>   
>>   
>> /
>> +  Name  : immsv_oi_augment_ccb_get_admo_name
>> +
>> +  Description   : The function gets adminoperation name from the CcbID.
>> +  For the saImmOiAugmentCcbInitialize when the ROF flag is false
>> +  for the original adminOperation name(#1956).
>> +
>> +  Arguments :  privateOmHandle - IMM OM handle
>> +   ccbId  -  The ccbId from the completed callback .
>> +   admoNameOut - The 

Re: [devel] [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in completed callback[#1956]

[Neelakanta Reddy]

Hi Hung,

Multiple adminowners are allowed for each immhandle
Multiple ccbhandles(IDs) allowed for each adminownerhandle

If we need to store in the OI cb , then we have to book-keep ccbids and 
there corresponding ccb operation object name

Instead I chose to read from IMMND , as AccessorGet or new message will 
have to get admin owner from IMMND.

Thanks,
Neel.

On 2016/11/23 01:47 PM, Hung Nguyen wrote:
> Hi Neel,
>
> I think we can fix this ticket without new message type.
>
> Before the CcbCompleted callback, the OI always gets one or more 
> CcbCreate/Modify/Delete callbacks.
> We can use those callbacks to get admo name.
>
> We add more members to 'struct imma_oi_ccb_record'
> SaStringT firstObjectName;
> SaStringT adminOwnerName;
>
>
> CcbCreate callback:
> We can get the admo name right away
> by reading 'SaImmAttrAdminOwnerName' attribute from 
> 'evt->info.objCreate.attrValues'
> Then store the admo name in imma_oi_ccb_record.adminOwnerName.
>
>
> CcbModify/Delete callback:
> We can't get the admo name right away.
> We have to store the object name in imma_oi_ccb_record.firstObjectName.
> This only needs to be done once, no need to overwrite 'firstObjectName' in 
> later callbacks.
> We only need one object name of the CCB.
>
>
> Now when we need to get admo name in CcbCompleted callback,
> we have to fetch the imma_oi_ccb_record of that ccb.
> If the ccb_record already has adminOwnerName, we can use it right away.
> If the ccb_record only has firstObjectName, use saImmOmAccessorGet_2 to 
> retrieve the admo name.
>
>
> BR,
> Hung Nguyen - DEK Technologies
>
> 
> From: Neelakanta reddyreddy.neelaka...@oracle.com
> Sent: Friday, November 18, 2016 9:54PM
> To: Zoran Milinkovic, Hung Nguyen
>  zoran.milinko...@ericsson.com,hung.d.ngu...@dektech.com.au
> Cc: Opensaf-devel
>  opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 1] imm:allow augumentCcbInit with ROF as false in 
> completed callback[#1956]
>
>
>   osaf/libs/agents/saf/imma/imma_oi_api.c|  156 
> +---
>   osaf/libs/common/immsv/immsv_evt.c |   49 ++--
>   osaf/libs/common/immsv/include/immsv_evt.h |2 +
>   osaf/services/saf/immsv/immnd/ImmModel.cc  |   39 +++
>   osaf/services/saf/immsv/immnd/ImmModel.hh  |3 +
>   osaf/services/saf/immsv/immnd/immnd_evt.c  |   65 
>   osaf/services/saf/immsv/immnd/immnd_init.h |3 +
>   7 files changed, 284 insertions(+), 33 deletions(-)
>
>
> with saImmOmCcbObjectRead, completed callback is also allowed to call 
> saImmOiAugmentCcbInitialize.
>   When ROF is false the augumentInit will get new adminowner with same name 
> as old adminowner name with ROF as true.
>
> Since, object name is not set for completed callback, a new event from OI to 
> IMMND is required to get adminownername from ccbID
> The patch inroduces new event by sending ccbID and response of the event will 
> be the adminname of the corresponding ccbId.
>
> diff --git a/osaf/libs/agents/saf/imma/imma_oi_api.c 
> b/osaf/libs/agents/saf/imma/imma_oi_api.c
> --- a/osaf/libs/agents/saf/imma/imma_oi_api.c
> +++ b/osaf/libs/agents/saf/imma/imma_oi_api.c
> @@ -3617,6 +3617,97 @@ getAdmoName(SaImmHandleT privateOmHandle
>   }
>   
>   
> /
> +  Name  : immsv_oi_augment_ccb_get_admo_name
> +
> +  Description   : The function gets adminoperation name from the CcbID.
> +   For the saImmOiAugmentCcbInitialize when the ROF flag is false
> +   for the original adminOperation name(#1956).
> +
> +  Arguments :  privateOmHandle - IMM OM handle
> +   ccbId  -  The ccbId from the completed callback .
> +   admoNameOut - The AdminOperation name of the ccbId
> +timeout - synchronous timeout
> +
> +  Return Values :  SA_AIS_OK
> +   SA_AIS_ERR_BAD_HANDLE
> +
> +**/
> +
> +SaAisErrorT immsv_oi_augment_ccb_get_admo_name(
> +   SaImmHandleT privateOmHandle,
> +SaUint32T ccbId,
> +   SaStringT  *admoNameOut,
> +SaTimeT timeout)
> +
> +{
> +SaAisErrorT rc = SA_AIS_OK;
> + IMMA_CB *cb = _cb;
> + uint32_t proc_rc;
> + IMMSV_EVT evt;
> + IMMSV_EVT *out_evt = NULL;
> + SaStringT * admtmp;
> +TRACE_ENTER();
> +
> + memset(, 0, sizeof(IMMSV_EVT));
> +evt.type = IMMSV_EVT_TYPE_IMMND;
> +evt.info.immnd.type = IMMND_EVT_A2ND_OI_AUG_CCB_GET_ADMO;
> + evt.info.immnd.info.ccbId = ccbId;
> +
> + proc_rc = imma_mds_msg_sync_send(cb->imma_mds_hdl, >immnd_mds_dest, 
> , _evt, timeout);
> + switch(proc_rc) {
> +case NCSCC_RC_SUCCESS:
> +break;
> +
> +  

Re: [devel] [PATCH 1 of 1] smf: Fix for #2066 does not build on 32bit [#2185]

[Neelakanta Reddy]

Hi Lennart,

Reviewed the patch.
Ack.

/Neel.

On 2016/11/15 02:07 PM, Lennart Lund wrote:
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> Fix a TRACE using %ld
>
> diff --git a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc 
> b/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
> --- a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
> +++ b/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
> @@ -3708,7 +3708,7 @@ bool SmfAdminOperation::nodeGroupAdminOp
>   base::Timer adminOpTimer(smfd_cb->adminOpTimeout / kNanoMillis);
>   
>   while (adminOpTimer.is_timeout() == false) {
> - TRACE("%s: saImmOmAdminOperationInvoke_2 time left = %ld",
> + TRACE("%s: saImmOmAdminOperationInvoke_2 time left = %" PRIu64,
>__FUNCTION__, adminOpTimer.time_left());
>   imm_rc = saImmOmAdminOperationInvoke_2(
>   m_ownerHandle,


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

Re: [devel] [PATCH 1 of 1] smfd: add support for asynchronous detection of failed AMF entities [#2145]

[Neelakanta Reddy]

Hi Alex,

I am waiting #2144 to be pushed(fixed) before this. Testing the #2145 
requires #2144 to be fixed.

The patch may not be backward compatible.
while upgrading from 5.1 to 5.2, consider the campaign having 
applications along with middle-ware components.
There may be a chance that the (application)software that is just 
upgraded in one of the SC will go to software disable.
The campaign will go to "suspended-by-error-detected" and the upgrade 
will fail.

Older, campaigns without modification may fail.


Thanks,
Neel.

On 2016/11/15 02:51 AM, Alex Jones wrote:
> Hi Lennart,
>
>The only way this new code would be different from the legacy behavior
> is if there is a bug in the newly updated software. If the software that
> was just updated goes into AMF DISABLED operational state while the
> campaign is still running, the campaign would then go into
> "suspended-by-error-detected", and the failed SU would be shown in
> saSmfCmpgError attribute.
>
>In the "legacy" version, SMF would not detect that the new software
> crashed, and would continue the campaign.
>
>It's not that the old behavior is not correct, it's that asynchronous
> errors of AMF entities were not handled.
>
>Can you give a specific scenario of what you would consider
> non-backwards-compatible?
>
> Alex
>
> On 11/14/2016 10:28 AM, Lennart Lund wrote:
>> 
>> NOTICE: This email was received from an EXTERNAL sender
>> 
>>
>> Hi Alex
>>
>> Your code adds a not previously implemented behavior correctly according
>> to the AIS. The problem is that I think this new correct behavior
>> differs from the 'legacy' behavior. So even if the new behavior is
>> correct and the old is not it is still NBC since some existing system
>> using SMF may not work correctly after the change is introduced. These
>> kind of problems are usually handled by making the new feature
>> configurable in such a way that the legacy behavior is default.
>> But please correct me if I have misunderstood how your change is working
>> in this aspect
>>
>> Thanks
>> Lennart
>>
>>> -Original Message-
>>> From: Alex Jones [mailto:ajo...@genband.com]
>>> Sent: den 14 november 2016 15:47
>>> To: Lennart Lund ;
>>> reddy.neelaka...@oracle.com; Rafael Odzakow
>>> 
>>> Cc: opensaf-devel@lists.sourceforge.net
>> 
>>> Subject: Re: [devel] [PATCH 1 of 1] smfd: add support for asynchronous
>>> detection of failed AMF entities [#2145]
>>>
>>> Hi Lennart,
>>>
>>> I'm not sure I understand this. Can you explain why you think this is
>>> not backwards compatible?
>>>
>>> This new functionality will put the campaign into "suspended by error
>>> detected" if any new/upgraded SU (or component in the SU) fails during
>>> the campaign (after it has been upgraded).
>>>
>>> Alex
>>>
>>> On 11/14/2016 09:35 AM, Lennart Lund wrote:
 
 NOTICE: This email was received from an EXTERNAL sender
 

 Hi Alex

 After I posted this ack I and Rafael found a possible Non backwards
 compatibility (NBC) problem. If so this must be solved before pushing.

 I believe this change introduce a new behavior when campaigns are
 executed if a component is failing. If I am right this could be solved
 by introducing a new attribute in the SMF configuration class that makes
 it possible to switch on/off this new behavior. The default must be that
 it is switched off (legacy behavior) also the absence of the new
 attribute must be interpreted as off (legacy)

 Thanks
 Lennart

> -Original Message-
> From: Lennart Lund [mailto:lennart.l...@ericsson.com]
> Sent: den 14 november 2016 13:56
> To: Alex Jones ; reddy.neelaka...@oracle.com;
> Rafael Odzakow 
> Cc: opensaf-devel@lists.sourceforge.net
>> 
 
> Subject: Re: [devel] [PATCH 1 of 1] smfd: add support for asynchronous
> detection of failed AMF entities [#2145]
>
> Hi Alex
>
> Ack with comment
> See my comments/questions inline [Lennart]
>
> Thanks
> Lennart
>
>> -Original Message-
>> From: Alex Jones [mailto:ajo...@genband.com]
>> Sent: den 11 november 2016 20:50
>> To: reddy.neelaka...@oracle.com; Lennart Lund
>> ; Rafael Odzakow
>> 
>> Cc: opensaf-devel@lists.sourceforge.net
>> 
 
>> 

Re: [devel] [PATCH 1 of 1] smf: Fails to create a node group, admin owner/handle is lost [#2153]

[Neelakanta Reddy]

Hi Lennart,

Reviewed the patch.
Ack.

/Neel.

On 2016/11/11 09:27 PM, Lennart Lund wrote:
> Hi Neel,
>
> "What is the reason for retrying fro BAD_OPERATION?"
> In order to create a Node Group several handles has to be created. A Failed 
> handle will result in return code BAD_HANDLE
> It is also needed to become admin owner of node group parent. It is also 
> possible that we still have a valid handle but not a valid admin owner. This 
> will result in return code BAD_OPERATION
>
> Thanks
> Lennart
>
>
>> -Original Message-
>> From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
>> Sent: den 11 november 2016 06:07
>> To: Lennart Lund <lennart.l...@ericsson.com>; Rafael Odzakow
>> <rafael.odza...@ericsson.com>
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [PATCH 1 of 1] smf: Fails to create a node group, admin
>> owner/handle is lost [#2153]
>>
>> Hi Lennart,
>>
>> comments inline
>>
>> On 2016/11/07 05:42 PM, Lennart Lund wrote:
>>>osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  46
>> +++--
>>>osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh |   1 +
>>>2 files changed, 36 insertions(+), 11 deletions(-)
>>>
>>>
>>> Recreate handles and admin owner if creating a node group fail
>>>
>>> diff --git a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
>> b/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
>>> --- a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
>>> +++ b/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
>>> @@ -2816,6 +2816,17 @@ SmfAdminOperation::SmfAdminOperation(std
>>> m_smfKeepDuState = true;
>>> }
>>>
>>> +   // Create an instance unique name for a node group IMM object
>>> +   // using an instance number.
>>> +   m_instance_number = m_next_instance_number++;
>>> +   m_instanceNodeGroupName =
>> "safAmfNodeGroup=smfLockAdmNg"+
>>> +   std::to_string(m_instance_number);
>>> +   m_admin_owner_name ="smfNgAdmOwnerName";
>>> +   TRACE("%s m_instanceNodeGroupName '%s'",__FUNCTION__,
>>> +   m_instanceNodeGroupName.c_str());
>>> +   TRACE("%s m_NodeGroupAdminOwnerName '%s'",
>> __FUNCTION__,
>>> +   m_admin_owner_name.c_str());
>>> +
>>> // Note:
>>> // If any of the following steps fails m_creation_fail is set to true
>>> // and an immediate return is done
>>> @@ -2835,12 +2846,6 @@ SmfAdminOperation::SmfAdminOperation(std
>>> m_creation_fail = true;
>>> return;
>>> }
>>> -
>>> -   // Create an instance unique name for a node group IMM object
>> using an
>>> -   // instance number.
>>> -   m_instance_number = m_next_instance_number++;
>>> -   m_instanceNodeGroupName =
>> "safAmfNodeGroup=smfLockAdmNg"+
>>> -   std::to_string(m_instance_number);
>>>}
>>>
>>>SmfAdminOperation::~SmfAdminOperation()
>>> @@ -3103,7 +3108,8 @@ bool SmfAdminOperation::initNodeGroupOm(
>>> timeout_try_cnt = 6;
>>> while (timeout_try_cnt > 0) {
>>> ais_rc =
>> immutil_saImmOmAdminOwnerInitialize(m_omHandle,
>>> -   const_cast<char*>
>> ("smfSetAdminStateOwner"),
>>> +   const_cast<char*>
>>> +   (m_admin_owner_name.c_str()),
>>> SA_TRUE, _ownerHandle);
>>> if (ais_rc != SA_AIS_ERR_TIMEOUT)
>>> break;
>>> @@ -3162,7 +3168,8 @@ bool SmfAdminOperation::becomeAdminOwner
>>> objectNames,
>> SA_IMM_SUBTREE);
>>> bool rc = true;
>>> if (ais_rc != SA_AIS_OK) {
>>> -   LOG_NO("%s: saImmOmAdminOwnerSet Fail '%s'",
>> __FUNCTION__,
>>> +   LOG_NO("%s: saImmOmAdminOwnerSet owner name '%s'
>> Fail '%s'",
>>> +   __FUNCTION__, m_admin_owner_name.c_str(),
>>> saf_error(ais_rc));
>>> }
>>>
>>> @@ -3470,7 +3477,9 @@ bool SmfAdminOperation::createNodeGroup(
>>>{
>>> TRACE_ENTER();
>>>
>>> -   TRACE("\t uniqueNodeName '%s'",
>> m_instanceNodeGroupName.c_str());
>>> +   TRACE("\t unique

Re: [devel] [PATCH 0 of 1] Review Request for imm: Fix external linkage in OI library [#2167]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2016/11/04 10:12 AM, Hung Nguyen wrote:
> Summary: imm: Fix external linkage in OI library [#2167]
> Review request for Trac Ticket(s): 2167
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.0, 5.1, 5.2
> Development branch: 5.2
>
> 
> 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 73e7264e41a3384b920d4bbb7dd9fcd3384ef6d1
> Author:   Hung Nguyen 
> Date: Fri, 04 Nov 2016 11:40:41 +0700
>
>   imm: Fix external linkage in OI library [#2167]
>
>   Fix external linkage in OI library.
>
>
> Complete diffstat:
> --
>   osaf/libs/agents/saf/imma/imma_oi_api.c |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 1 of 1] smf: Fails to create a node group, admin owner/handle is lost [#2153]

[Neelakanta Reddy]

Hi Lennart,

comments inline

On 2016/11/07 05:42 PM, Lennart Lund wrote:
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  46 
> +++--
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh |   1 +
>   2 files changed, 36 insertions(+), 11 deletions(-)
>
>
> Recreate handles and admin owner if creating a node group fail
>
> diff --git a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc 
> b/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
> --- a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
> +++ b/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
> @@ -2816,6 +2816,17 @@ SmfAdminOperation::SmfAdminOperation(std
>   m_smfKeepDuState = true;
>   }
>   
> + // Create an instance unique name for a node group IMM object
> + // using an instance number.
> + m_instance_number = m_next_instance_number++;
> + m_instanceNodeGroupName = "safAmfNodeGroup=smfLockAdmNg"+
> + std::to_string(m_instance_number);
> + m_admin_owner_name ="smfNgAdmOwnerName";
> + TRACE("%s m_instanceNodeGroupName '%s'",__FUNCTION__,
> + m_instanceNodeGroupName.c_str());
> + TRACE("%s m_NodeGroupAdminOwnerName '%s'", __FUNCTION__,
> + m_admin_owner_name.c_str());
> +
>   // Note:
>   // If any of the following steps fails m_creation_fail is set to true
>   // and an immediate return is done
> @@ -2835,12 +2846,6 @@ SmfAdminOperation::SmfAdminOperation(std
>   m_creation_fail = true;
>   return;
>   }
> -
> - // Create an instance unique name for a node group IMM object using an
> - // instance number.
> - m_instance_number = m_next_instance_number++;
> - m_instanceNodeGroupName = "safAmfNodeGroup=smfLockAdmNg"+
> - std::to_string(m_instance_number);
>   }
>   
>   SmfAdminOperation::~SmfAdminOperation()
> @@ -3103,7 +3108,8 @@ bool SmfAdminOperation::initNodeGroupOm(
>   timeout_try_cnt = 6;
>   while (timeout_try_cnt > 0) {
>   ais_rc = immutil_saImmOmAdminOwnerInitialize(m_omHandle,
> - const_cast ("smfSetAdminStateOwner"),
> + const_cast
> + (m_admin_owner_name.c_str()),
>   SA_TRUE, _ownerHandle);
>   if (ais_rc != SA_AIS_ERR_TIMEOUT)
>   break;
> @@ -3162,7 +3168,8 @@ bool SmfAdminOperation::becomeAdminOwner
>   objectNames, SA_IMM_SUBTREE);
>   bool rc = true;
>   if (ais_rc != SA_AIS_OK) {
> - LOG_NO("%s: saImmOmAdminOwnerSet Fail '%s'", __FUNCTION__,
> + LOG_NO("%s: saImmOmAdminOwnerSet owner name '%s' Fail '%s'",
> + __FUNCTION__, m_admin_owner_name.c_str(),
>   saf_error(ais_rc));
>   }
>   
> @@ -3470,7 +3477,9 @@ bool SmfAdminOperation::createNodeGroup(
>   {
>   TRACE_ENTER();
>   
> - TRACE("\t uniqueNodeName '%s'", m_instanceNodeGroupName.c_str());
> + TRACE("\t unique Node name '%s'", m_instanceNodeGroupName.c_str());
> + TRACE("\t unique Admin owner name '%s'",
> + m_admin_owner_name.c_str());
>   
>   // 
>   // Attribute descriptor for the node name
> @@ -3556,7 +3565,7 @@ bool SmfAdminOperation::createNodeGroup(
>   // Create the node group
>   m_errno = SA_AIS_OK;
>   bool method_rc = false;
> -const uint32_t MAX_NO_RETRIES = 2;
> +const uint32_t MAX_NO_RETRIES = 4;
>   uint32_t retry_cnt = 0;
>   while (++retry_cnt <= MAX_NO_RETRIES) {
>   // Creating the node group object will fail if a previously
> @@ -3585,7 +3594,22 @@ bool SmfAdminOperation::createNodeGroup(
>   break;
>   }
>   continue;
> -} else if (m_errno != SA_AIS_OK) {
> +} else if (m_errno == SA_AIS_ERR_BAD_HANDLE ||
> +m_errno == SA_AIS_ERR_BAD_OPERATION) {
What is the reason for retrying fro BAD_OPERATION?

Thanks,
Neel.

> +LOG_NO("%s: saImmOmCcbObjectCreate_2 Fail %s",
> +   __FUNCTION__, saf_error(m_errno));
> +finalizeNodeGroupOm();
> +bool rc = initNodeGroupOm();
> +if (rc == false) {
> +LOG_NO("%s: initNodeGroupOm() Fail",
> +   __FUNCTION__);
> +method_rc = false;
> +break;
> +}
> + TRACE("\t Try again after %s",
> + saf_error(m_errno));
> +continue;
> + } else if (m_errno != SA_AIS_OK) {
>   LOG_NO("%s: 

Re: [devel] [PATCH 0 of 1] Review Request for smf: balanced upgrade, no activation/deactivation done [#2126]

[Neelakanta Reddy]

Hi Rafael,

The problem got reproduced.
The fix was good.
Ack from me.

Thanks,
Neel.

On 2016/10/28 05:54 PM, Rafael Odzakow wrote:
> Summary: smf: balanced upgrade, no activation/deactivation done [#2126]
> Review request for Trac Ticket(s): lennart, reddy
> Peer Reviewer(s): <>
> Pull request to: <>
> Affected branch(es): <>
> Development branch: <>
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>   <>
>
> changeset 66649005deec54cecff91df28f9095557faae1ad
> Author:   Rafael Odzakow 
> Date: Fri, 28 Oct 2016 14:12:37 +0200
>
>   smf:balanced upgrade, no activation/deactivation done [#2126]
>
>   Add the deactivation list to the balanced procedure, it was declared 
> but not
>   used.
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfExecControl.cc |  21 +++--
>   1 files changed, 11 insertions(+), 10 deletions(-)
>
>
> Testing Commands:
> -
>   <>
>
>
> Testing, Expected Results:
> --
>   <>
>
>
> Conditions of Submission:
> -
>   <>
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 0 of 1] Review Request for smf: Fix loop timeout in admin operation handling [#2066]

[Neelakanta Reddy]

Hi Lennart,

Reviewed the patch.
Ack.

/Neel.

On 2016/10/28 02:24 PM, Lennart Lund wrote:
> Summary: smf: Fix loop timeout in admin operation handling
> Review request for Trac Ticket(s): #2066
> Peer Reviewer(s): reddy.neelaka...@oracle.com, rafael.odza...@ericsson.com
> Pull request to: <>
> Affected branch(es): 5.1, default
> Development branch: <>
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
> Updated according to latest comments
>
> changeset b48e76e4aaa5e85b8664e555e34c2b1071bb7994
> Author:   Lennart Lund 
> Date: Fri, 28 Oct 2016 10:49:02 +0200
>
>   smf: Fix loop timeout in admin operation handling [#2066]
>
>   Fix handling of AMF admin operation so that adminOpTimeout is respected 
> both
>   for timeout of the synchronous saImmOmAdminOperationInvoke_2 IMM API and
>   when handling TRY AGAIN replies from both saImmOmAdminOperationInvoke_2 
> and
>   AMF OI
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  182 
> ++--
>   1 files changed, 99 insertions(+), 83 deletions(-)
>
>
> Testing Commands:
> -
>   <>
>
>
> Testing, Expected Results:
> --
>   <>
>
>
> Conditions of Submission:
> -
>   <>
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 0 of 1] Review Request for imm: Avoid hard coding attributes count in saImmOmAccessorGet_2_04 [#2140]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2016/10/25 04:24 PM, Hung Nguyen wrote:
> Summary: imm: Avoid hard coding attributes count in saImmOmAccessorGet_2_04 
> [#2140]
> Review request for Trac Ticket(s): 2140
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.2
> Development branch: 5.2
>
> 
> 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 fb55b86652d895b610cadba94df0ebc12e626cdc
> Author:   Hung Nguyen 
> Date: Tue, 25 Oct 2016 17:51:08 +0700
>
>   imm: Avoid hard coding attributes count in saImmOmAccessorGet_2_04 
> [#2140]
>
>   Avoid hard coding attributes count in saImmOmAccessorGet_2_04.
>
>
> Complete diffstat:
> --
>   tests/immsv/management/test_saImmOmAccessorGet_2.c |  15 ++-
>   1 files changed, 14 insertions(+), 1 deletions(-)
>
>
> Testing Commands:
> -
> immomtest 4 7
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] smf:read imm longdn attribute at campaigninit [#2119]

[Neelakanta Reddy]

Hi Rafael,

Comments inline.

On 2016/10/27 07:29 PM, Rafael Odzakow wrote:
> Questions below.
>
> On 10/21/2016 01:31 PM, reddy.neelaka...@oracle.com wrote:
>> osaf/services/saf/smfsv/smfd/SmfCampaignInit.cc |  17 +++--
>>   1 files changed, 15 insertions(+), 2 deletions(-)
>>
>>
>> diff --git a/osaf/services/saf/smfsv/smfd/SmfCampaignInit.cc 
>> b/osaf/services/saf/smfsv/smfd/SmfCampaignInit.cc
>> --- a/osaf/services/saf/smfsv/smfd/SmfCampaignInit.cc
>> +++ b/osaf/services/saf/smfsv/smfd/SmfCampaignInit.cc
>> @@ -225,11 +225,24 @@ SmfCampaignInit::execute()
>>   return false;
>>   }
>>   +TRACE("3. Read_IMM_long_DN_config_and_set_control_block()");
>> +if 
>> (!immUtil.read_IMM_long_DN_config_and_set_control_block(smfd_cb)) {
>> +LOG_ER("SmfCampaignInit: reading long DN config from IMM 
>> FAILED");
>> +TRACE_LEAVE();
>> +return false;
>> +}
> [rafael] looks to me that this block is enough to have in one place. 
> There is nothing going on between the block above and the start of the 
> while loop.
Yes, the above block may not be required.

>> +
>>   std::list < SmfUpgradeAction * >::iterator upActiter;
>>   upActiter = m_campInitAction.begin();
>>   while (upActiter != m_campInitAction.end()) {
>> -   SaAisErrorT rc = 
>> (*upActiter)->execute(SmfCampaignThread::instance()->getImmHandle(),
>> - );
>> +TRACE("4. %s: 
>> read_IMM_long_DN_config_and_set_control_block()",__FUNCTION__);
>> +if 
>> (!immUtil.read_IMM_long_DN_config_and_set_control_block(smfd_cb)) {
>> +LOG_ER("SmfCampaignInit: reading long DN config from IMM 
>> FAILED");
>> +TRACE_LEAVE();
>> +return false;
>> +}
> [rafael] Not sure why you would want to read the config before each 
> upgradeAction. Can you explain?
The reading of IMM longdnconfig attribute is required here.
The config attribute is read before each upgrade action, because
There is a chance, that the londn attribute is enabled in previous 
campInitAction and longdn operation is
performed in the next campInitAction.

once the Longdn is enabled,  then the IMM attribute is not read.
(The function "read_IMM_long_DN_config_and_set_control_block" has a 
condition to check if longdn are already enabled)

Eg:
 
 
 
 
1
 
 
 
 
 
 
 
 
openSafSmfMisc=ThisIsA300CharLongRDNaa
 
 
 LongDN 300 char 
parent object
 
 
 
 


  another review request  is required or the patch can be pushed, 
without the first block (which is not required).

Thanks,
Neel.

>> +SaAisErrorT rc = 
>> (*upActiter)->execute(SmfCampaignThread::instance()->getImmHandle(),
>> +);
>>   if (rc != SA_AIS_OK) {
>>   LOG_ER("SmfCampaignInit init action %d failed, rc=%s", 
>> (*upActiter)->getId(), saf_error(rc));
>>   TRACE_LEAVE();
>


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] smf:read imm longdn attribute at campaigninit [#2119]

[Neelakanta Reddy]

Hi Lennart,

Thanks, for the comment.
Open an enhancement ticket, for having an applier towards imm class.

/Neel.

On 2016/10/24 04:24 PM, Lennart Lund wrote:
> Hi Neel
>
> Ack with comments
>
> Tested that long DN setting during campaign init works again.
>
> The solution for reading this setting results in a lot of redundant code. 
> Reading of this setting from IMM and updating global variables is done in 
> many places (I have counted to 5). This is risky and hard to handle in a 
> threaded system.
> A better solution is probably to constantly keep track of changes of this 
> setting e.g. by using an IMM applier running in its own thread, not saving 
> the information in global variable (we should try to get rid of the cb 
> struct) and encapsulate all handling of this setting. The only thing that's 
> interesting in the rest of the code is the correct value. Nowhere in the code 
> it should be needed to handle this setting in any other way than to read it.
>
> Thanks
> Lennart
>
>> -Original Message-
>> From: reddy.neelaka...@oracle.com [mailto:reddy.neelaka...@oracle.com]
>> Sent: den 21 oktober 2016 13:32
>> To: Lennart Lund ; Rafael Odzakow
>> 
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: [PATCH 1 of 1] smf:read imm longdn attribute at campaigninit
>> [#2119]
>>
>>   osaf/services/saf/smfsv/smfd/SmfCampaignInit.cc |  17
>> +++--
>>   1 files changed, 15 insertions(+), 2 deletions(-)
>>
>>
>> diff --git a/osaf/services/saf/smfsv/smfd/SmfCampaignInit.cc
>> b/osaf/services/saf/smfsv/smfd/SmfCampaignInit.cc
>> --- a/osaf/services/saf/smfsv/smfd/SmfCampaignInit.cc
>> +++ b/osaf/services/saf/smfsv/smfd/SmfCampaignInit.cc
>> @@ -225,11 +225,24 @@ SmfCampaignInit::execute()
>>   return false;
>>   }
>>
>> +TRACE("3. Read_IMM_long_DN_config_and_set_control_block()");
>> +if
>> (!immUtil.read_IMM_long_DN_config_and_set_control_block(smfd_cb)) {
>> +LOG_ER("SmfCampaignInit: reading long DN config from IMM
>> FAILED");
>> +TRACE_LEAVE();
>> +return false;
>> +}
>> +
>>  std::list < SmfUpgradeAction * >::iterator upActiter;
>>  upActiter = m_campInitAction.begin();
>>  while (upActiter != m_campInitAction.end()) {
>> -SaAisErrorT rc = (*upActiter)-
>>> execute(SmfCampaignThread::instance()->getImmHandle(),
>> -   );
>> +TRACE("4. %s:
>> read_IMM_long_DN_config_and_set_control_block()",__FUNCTION__);
>> +if
>> (!immUtil.read_IMM_long_DN_config_and_set_control_block(smfd_cb)) {
>> +LOG_ER("SmfCampaignInit: reading long DN config
>> from IMM FAILED");
>> +TRACE_LEAVE();
>> +return false;
>> +}
>> +SaAisErrorT rc = (*upActiter)-
>>> execute(SmfCampaignThread::instance()->getImmHandle(),
>> +);
>>  if (rc != SA_AIS_OK) {
>>  LOG_ER("SmfCampaignInit init action %d failed,
>> rc=%s", (*upActiter)->getId(), saf_error(rc));
>>  TRACE_LEAVE();


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] imm: Convert syslog message to TRACE, to avoid filling up the syslog [#2136]

[Neelakanta Reddy]

Hi Anders,

Reviewed the patch.
Ack.

/Neel.

On 2016/10/24 04:45 PM, Anders Widell wrote:
>   osaf/services/saf/immsv/immnd/ImmModel.cc |  4 ++--
>   1 files changed, 2 insertions(+), 2 deletions(-)
>
>
> After a commit of an SMF campaign, the syslog was filled with thousands of log
> messages with the text "Delete of PERSISTENT runtime object ...". Since the
> syslog is a global log for all applications running on a node, OpenSAF ought 
> to
> be careful to not produce an excessive amount of syslog messages. The message
> has therefore been converted to a trace message.
>
> diff --git a/osaf/services/saf/immsv/immnd/ImmModel.cc 
> b/osaf/services/saf/immsv/immnd/ImmModel.cc
> --- a/osaf/services/saf/immsv/immnd/ImmModel.cc
> +++ b/osaf/services/saf/immsv/immnd/ImmModel.cc
> @@ -16592,10 +16592,10 @@ SaInt32T ImmModel::pbePrtObjDeletesConti
>   if(error == SA_AIS_OK) {
>   if(oMut->mAfterImage->mObjFlags & IMM_PRTO_FLAG) {
>   if(oMut->mAfterImage->mImplementer) {
> -LOG_NO("Delete of PERSISTENT runtime object '%s' (%s).", 
> i2->first.c_str(),
> +TRACE("Delete of PERSISTENT runtime object '%s' (%s).", 
> i2->first.c_str(),
>   
> oMut->mAfterImage->mImplementer->mImplementerName.c_str());
>   } else {
> -LOG_NO("Delete of PERSISTENT runtime object '%s' (%s).", 
> i2->first.c_str(),
> +TRACE("Delete of PERSISTENT runtime object '%s' (%s).", 
> i2->first.c_str(),
>   "");
>   }
>   } else {


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

Re: [devel] [PATCH 1 of 1] imm: Store mScAbsenceAllowed as 32 bit unsigned integer [#2130]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2016/10/21 10:08 AM, Hung Nguyen wrote:
>   osaf/services/saf/immsv/immd/immd_cb.h|   4 +-
>   osaf/services/saf/immsv/immd/immd_main.c  |   2 +-
>   osaf/services/saf/immsv/immd/immd_mbcsv.c |  32 
> +++---
>   osaf/services/saf/immsv/immnd/ImmModel.cc |   2 +-
>   osaf/services/saf/immsv/immnd/ImmModel.hh |   2 +-
>   osaf/services/saf/immsv/immnd/immnd_cb.h  |   2 +-
>   6 files changed, 34 insertions(+), 10 deletions(-)
>
>
> Store mScAbsenceAllowed as 32 bit unsigned integer.
>
> diff --git a/osaf/services/saf/immsv/immd/immd_cb.h 
> b/osaf/services/saf/immsv/immd/immd_cb.h
> --- a/osaf/services/saf/immsv/immd/immd_cb.h
> +++ b/osaf/services/saf/immsv/immd/immd_cb.h
> @@ -39,7 +39,7 @@
>IMMD_WRT_IMMND_SUBPART_VER_MIN + 1 )
>   
>   #define IMMSV_IMMD_MBCSV_VERSION_MIN 4
> -#define IMMSV_IMMD_MBCSV_VERSION 6
> +#define IMMSV_IMMD_MBCSV_VERSION 7
>   
>   typedef struct immd_saved_fevs_msg {
>   IMMSV_FEVS fevsMsg;
> @@ -139,7 +139,7 @@ typedef struct immd_cb_tag {
>   bool m2PbeExtraWait;/* true => Used only to prolong wait if both SCs
>  have been introduced but one has not yet 
> replied. */
>   bool nid_started;   /* true if started by NID */
> - SaUint16T mScAbsenceAllowed; /* Non zero if SC absence is allowed (loss 
> of both IMMDs/SCs).
> + SaUint32T mScAbsenceAllowed; /* Non zero if SC absence is allowed (loss 
> of both IMMDs/SCs).
>  Value is number of seconds of SC absence 
> tolerated. */
>   MDS_DEST payload_coord_dest; /* IMMND coord may be at payload if 
> mScAbsenceAllowed is nonzero */
>   uint32_t mScAbsenceVeteranMaxWait; /* Amount of seconds IMMD waits for 
> veteran IMMDs after sc absence */
> diff --git a/osaf/services/saf/immsv/immd/immd_main.c 
> b/osaf/services/saf/immsv/immd/immd_main.c
> --- a/osaf/services/saf/immsv/immd/immd_main.c
> +++ b/osaf/services/saf/immsv/immd/immd_main.c
> @@ -276,7 +276,7 @@ int main(int argc, char *argv[])
>   int64_t start_time = 0LL;
>   uint32_t print_at_secs = 1LL;
>   int term_fd;
> - uint16_t scAbsenceAllowed = 0;
> + uint32_t scAbsenceAllowed = 0;
>   
>   daemonize(argc, argv);
>   
> diff --git a/osaf/services/saf/immsv/immd/immd_mbcsv.c 
> b/osaf/services/saf/immsv/immd/immd_mbcsv.c
> --- a/osaf/services/saf/immsv/immd/immd_mbcsv.c
> +++ b/osaf/services/saf/immsv/immd/immd_mbcsv.c
> @@ -770,11 +770,19 @@ static uint32_t mbcsv_enc_msg_resp(IMMD_
>   ncs_encode_8bit(_ptr, cb->mIs2Pbe);
>   }
>   
> - if (peer_version >= 6) {
> + /* See ticket #2130 */
> + if (peer_version == 6) {
>   uns16_ptr = ncs_enc_reserve_space(>info.encode.io_uba, 
> sizeof(uint16_t));
>   osafassert(uns16_ptr);
>   ncs_enc_claim_space(>info.encode.io_uba, sizeof(uint16_t));
> - ncs_encode_16bit(_ptr, cb->mScAbsenceAllowed);
> + ncs_encode_16bit(_ptr, (uint16_t) cb->mScAbsenceAllowed);
> + }
> +
> + if (peer_version >= 7) {
> + uns32_ptr = ncs_enc_reserve_space(>info.encode.io_uba, 
> sizeof(uint32_t));
> + osafassert(uns32_ptr);
> + ncs_enc_claim_space(>info.encode.io_uba, sizeof(uint32_t));
> + ncs_encode_32bit(_ptr, cb->mScAbsenceAllowed);
>   }
>   
>   /* Alter this to follow same pattern as logsv */
> @@ -1184,16 +1192,32 @@ static uint32_t mbcsv_dec_sync_resp(IMMD
>   }
>   }
>   
> - if (peer_version >= 6) {
> + /* See ticket #2130 */
> + if (peer_version == 6) {
>   uint16_t scAbsenceAllowed;
>   
>   ptr = ncs_dec_flatten_space(>info.decode.i_uba, data, 
> sizeof(uint16_t));
>   scAbsenceAllowed = ncs_decode_16bit();
>   ncs_dec_skip_space(>info.decode.i_uba, sizeof(uint16_t));
>   
> + if((uint16_t) cb->mScAbsenceAllowed != scAbsenceAllowed) {
> + LOG_ER("SC absence allowed in not the same as on active 
> IMMD. "
> + "Active: %u, Standby: %u. Exiting.",
> + scAbsenceAllowed, (uint16_t) 
> cb->mScAbsenceAllowed);
> + exit(1);
> + }
> + }
> +
> + if (peer_version >= 7) {
> + uint32_t scAbsenceAllowed;
> +
> + ptr = ncs_dec_flatten_space(>info.decode.i_uba, data, 
> sizeof(uint32_t));
> + scAbsenceAllowed = ncs_decode_32bit();
> + ncs_dec_skip_space(>info.decode.i_uba, sizeof(uint32_t));
> +
>   if(cb->mScAbsenceAllowed != scAbsenceAllowed) {
>   LOG_ER("SC absence allowed in not the same as on active 
> IMMD. "
> - "Active: %u, Standby: %d. Exiting.",
> + "Active: %u, Standby: %u. Exiting.",
> 

Re: [devel] [PATCH 0 of 1] Review Request for imm: Fix error handling path when imma_sync_with_immnd fails [#2131]

[Neelakanta Reddy]

Hi Anders,

Reviewed the patch.
Ack.

/Neel.

On 2016/10/20 04:22 PM, Anders Widell wrote:
> Summary: imm: Fix error handling path when imma_sync_with_immnd fails [#2131]
> Review request for Trac Ticket(s): 2131
> Peer Reviewer(s): Neelakanta, Zoran, Hung
> Pull request to:
> Affected branch(es): opensaf-5.0.x, opensaf-5.1.x, default(5.2)
> 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 a62c9eeebf3407af30feaa0b4f1486a1186eeb35
> Author:   Anders Widell 
> Date: Thu, 20 Oct 2016 12:44:46 +0200
>
>   imm: Fix error handling path when imma_sync_with_immnd fails [#2131]
>
>   Since we have called imma_mds_register() at the point where
>   imma_sync_with_immnd() is called, we must call imma_mds_unregister() in 
> the
>   error handling path.
>
>
> Complete diffstat:
> --
>   osaf/libs/agents/saf/imma/imma_init.c |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> Testing Commands:
> -
> Inject an error that will cause imma_sync_with_immnd() to fail.
>
>
> Testing, Expected Results:
> --
> No core dump expected.
>
>
> Conditions of Submission:
> -
> Ack from at least two reviers.
>
>
> 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

Re: [devel] [PATCH 0 of 1] Review Request for immtool: Print out enum name for SAF error code [#2123]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2016/10/18 12:28 PM, Hung Nguyen wrote:
> Summary: immtool: print out enum name for SAF error code [#2123]
> Review request for Trac Ticket(s): 2123
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.2
> Development branch: 5.2
>
> 
> 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 97d866a07805cf0e4ad42ba8dcedb90ae0adc68a
> Author:   Hung Nguyen 
> Date: Tue, 18 Oct 2016 13:55:48 +0700
>
>   immtool: print out enum name for SAF error code [#2123]
>
>   Print out enum name for SAF error code.
>
>
> Complete diffstat:
> --
>   osaf/tools/safimm/immcfg/imm_cfg.c |  26 +-
>   osaf/tools/safimm/immcfg/imm_import.cc |  41 
> +
>   2 files changed, 34 insertions(+), 33 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 0 of 1] Review Request for imm: Dont send ND2ND_ADMOP_RSP message when OI and OM client are on the same node [#2113]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2016/10/17 11:30 AM, Hung Nguyen wrote:
> Summary: imm: Don't send ND2ND_ADMOP_RSP message when OI and OM client are on 
> the same node [#2113]
> Review request for Trac Ticket(s): 2113
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.0, 5.1, 5.2
> Development branch: 5.2
>
> 
> 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 05528fb36a9f19c6edbda844a2da98b0ff015f49
> Author:   Hung Nguyen 
> Date: Mon, 17 Oct 2016 11:21:41 +0700
>
>   imm: Don't send ND2ND_ADMOP_RSP message when OI and OM client are on the
>   same node [#2113]
>
>   Don't send ND2ND_ADMOP_RSP message when OI and OM client are on the same
>   node.
>
>
> Complete diffstat:
> --
>   osaf/services/saf/immsv/immnd/immnd_evt.c |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 1 of 1] immtool: Don't finalize admo if it hasn't been initialized [#2107]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2016/10/11 09:27 AM, Hung Nguyen wrote:
>   osaf/tools/safimm/immcfg/imm_cfg.c |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> Don't finalize admo if it hasn't been initialized.
>
> diff --git a/osaf/tools/safimm/immcfg/imm_cfg.c 
> b/osaf/tools/safimm/immcfg/imm_cfg.c
> --- a/osaf/tools/safimm/immcfg/imm_cfg.c
> +++ b/osaf/tools/safimm/immcfg/imm_cfg.c
> @@ -1703,7 +1703,7 @@ static int imm_operation(int argc, char
>   }
>   }
>   
> - if(useAdminOwner) {
> + if(useAdminOwner && adminOwnerName) {
>   error = immutil_saImmOmAdminOwnerFinalize(ownerHandle);
>   if (SA_AIS_OK != error) {
>   fprintf(stderr, "error - 
> saImmOmAdminOwnerFinalize FAILED: %s\n", saf_error(error));


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

Re: [devel] [PATCH 1 of 1] smf: Fix loop timeout in admin operation handling [#2066]

[Neelakanta Reddy]

Hi Lennart,

Reviewed the patch.
Following are the comments:

1. The timeout for each admin operation must be "smfd_cb->adminOpTimeout".
The smfd_cb->adminOpTimeout is configurable, if the adminoperation 
timeout passed is less than smfd_cb->adminOpTimeout there is a chance, 
to get TIMEOUT.

2. The maximum number of retries can be 25 with a sleep of 
500millseconds(will be ideal).

Regards,
Neel.


On 2016/10/07 05:55 PM, Lennart Lund wrote:
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  253 
> 
>   1 files changed, 126 insertions(+), 127 deletions(-)
>
>
> Fix handling of AMF admin operation so that adminOpTimeout is
> respected both for timeout of the synchronous saImmOmAdminOperationInvoke_2
> IMM API and when handling TRY AGAIN replies from both 
> saImmOmAdminOperationInvoke_2
> and AMF OI
>
> diff --git a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc 
> b/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
> --- a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
> +++ b/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
> @@ -55,7 +55,7 @@
>   #include "immutil.h"
>   #include "smfd_smfnd.h"
>   #include "smfd.h"
> -#include "osaf_time.h"
> +#include "base/time.h"
>   
>   /* 
>*   DEFINITIONS
> @@ -3536,52 +3536,52 @@ bool SmfAdminOperation::createNodeGroup(
>   // 
>   // Create the node group
>   bool method_rc = false;
> -const uint32_t MAX_NO_RETRIES = 2;
> -uint32_t retry_cnt = 0;
> -while (++retry_cnt <= MAX_NO_RETRIES) {
> -// Creating the node group object will fail if a previously
> -// created node group was for some reason not deleted
> -// If that's the case (SA_AIS_ERR_EXIST) try to delete the
> -// node group and try again.
> -m_errno = immutil_saImmOmCcbObjectCreate_2(
> -m_ccbHandle,
> -className,
> -,
> -attrValues);
> -TRACE("%s: immutil_saImmOmCcbObjectCreate_2 %s",
> -__FUNCTION__, saf_error(m_errno));
> -
> -if (m_errno == SA_AIS_ERR_EXIST) {
> -// A node group with the same name already exist
> -// May happen if a previous delete after usage has
> -// failed
> -LOG_NO("%s: saImmOmCcbObjectCreate_2 Fail %s",
> -   __FUNCTION__, saf_error(m_errno));
> -bool rc = deleteNodeGroup();
> -if (rc == false) {
> -LOG_NO("%s: deleteNodeGroup() Fail",
> -   __FUNCTION__);
> -method_rc = false;
> -break;
> -}
> -continue;
> -} else if (m_errno != SA_AIS_OK) {
> -LOG_NO("%s: saImmOmCcbObjectCreate_2() '%s' Fail %s",
> -__FUNCTION__, nGnodeName, 
> saf_error(m_errno));
> -method_rc = false;
> -break;
> -} else {
> -m_errno = saImmOmCcbApply(m_ccbHandle);
> -if (m_errno != SA_AIS_OK) {
> -LOG_NO("%s: saImmOmCcbApply() Fail '%s'",
> -__FUNCTION__, saf_error(m_errno));
> -method_rc = false;
> -} else {
> -method_rc = true;
> -}
> -break;
> -}
> -}
> + const uint32_t MAX_NO_RETRIES = 2;
> + uint32_t retry_cnt = 0;
> + while (++retry_cnt <= MAX_NO_RETRIES) {
> + // Creating the node group object will fail if a previously
> + // created node group was for some reason not deleted
> + // If that's the case (SA_AIS_ERR_EXIST) try to delete the
> + // node group and try again.
> + m_errno = immutil_saImmOmCcbObjectCreate_2(
> +m_ccbHandle,
> +className,
> +,
> +attrValues);
> + TRACE("%s: immutil_saImmOmCcbObjectCreate_2 %s",
> +   __FUNCTION__, saf_error(m_errno));
> +
> + if (m_errno == SA_AIS_ERR_EXIST) {
> + // A node group with the same name already exist
> + // May happen if a previous delete after usage has
> + // failed
> + LOG_NO("%s: 

Re: [devel] [PATCH 1 of 1] smfd: handle failed middlware si-swap [#1605]

[Neelakanta Reddy]

Hi Alex,

I tested the patch,
when the same scenario is followed in the defect, the campaign is moving 
to SUSPENDED_BY_ERROR_DETECTED.

when the other controller comes up(which is rebooted in the middle of 
si-swap),

a) execute the campaign again, the campaign is moving to EXECUTION_FAILED.
b) rollback the campaign, the campaign us moving to ROLLBACK_COMPLETED.

The case (a), above has to be looked into, why the campaign is moving to 
EXECUTION_FAILED STATE.
The campaign, has to move to EXECUTION_COMPLETED state.

Reviewing the code, let you know if there are any further comments.

Regards,
Neel.


On 2016/10/06 01:50 AM, Alex Jones wrote:
>   osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |  69 
> +---
>   osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh |   6 +
>   2 files changed, 64 insertions(+), 11 deletions(-)
>
>
> Sep 27 00:34:14 q50-s1 osafsmfd[6667]: NO SA_AMF_ADMIN_SI_SWAP [rc=1] 
> successfully initiated
> Sep 27 00:34:15 q50-s1 osafimmnd[6571]: NO ERR_BAD_OPERATION: Mismatch on 
> administrative owner '' != 'SMFSERVICE'
> Sep 27 00:34:17 q50-s1 osafsmfd[6667]: NO Fail to invoke admin operation, 
> rc=SA_AIS_ERR_BAD_OPERATION (20). dn=[safSi=SC-2N,safApp=OpenSAF], opId=[7]
> Sep 27 00:34:17 q50-s1 osafsmfd[6667]: NO Admin op SA_AMF_ADMIN_SI_SWAP fail 
> [rc = 20]
> Sep 27 00:34:17 q50-s1 osafsmfd[6667]: NO CAMP: Procedure 
> safSmfProc=RollingUpgrade returned FAILED
> Sep 27 00:36:14 q50-s1 osafsmfd[6667]: NO Campaign thread does not disappear 
> within 120 seconds after SA_AMF_ADMIN_SI_SWAP, the operation was assumed 
> failed.
> Sep 27 00:36:14 q50-s1 kernel: [14934029.531187] osafsmfd[32024]: segfault at 
> 4 ip 004425b6 sp 7f67f7ffe1c0 error 4 in osafsmfd[40+9a000]
> Sep 27 00:36:14 q50-s1 osafamfnd[6649]: NO 
> 'safComp=SMF,safSu=SC-1,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown' : 
> Recovery is 'nodeFailfast'
> Sep 27 00:36:14 q50-s1 osafamfnd[6649]: ER 
> safComp=SMF,safSu=SC-1,safSg=2N,safApp=OpenSAF Faulted due to:avaDown 
> Recovery is:nodeFailfast
>
> There are a few problems here. One is that the SmfSwapThread is pointing to a
> deleted procedure when the original active controller is reassigned active. 
> The
> second problem is that a new SmfSwapThread is created when the original active
> controller is reassigned active, so now there are two running. The first 
> thread
> tries to use its proc pointer (which has been deleted when the original active
> goes to quiesced) and causes the segfault.
>
> The proposed solution is a little different from that proposed in the ticket
> description. This solution proposes to use the existence of the SmfSwapThread 
> as
> a test. When the original active controller is reassigned active because the
> si-swap failed, it will still remove the RestartIndicator as it does now. But,
> if the SmfSwapThread is still running, it will not create a new one, but 
> update
> it with the recreated procedure pointer, and let it handle the si-swap 
> timeout.
> Then it will report the error. I believe this solution is backwards compatible
> because no IMM changes are made like the ones proposed in the ticket.
>
> diff --git a/osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc 
> b/osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc
> --- a/osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc
> +++ b/osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc
> @@ -482,12 +482,18 @@ SmfUpgradeProcedure::switchOver()
>   osafassert(0);
>   }
>   
> - TRACE("SmfUpgradeProcedure::switchOver: Create the restart indicator");
> - 
> SmfCampaignThread::instance()->campaign()->getUpgradeCampaign()->createSmfRestartIndicator();
> -
> - SmfSwapThread *swapThread = new SmfSwapThread(this);
> - TRACE("SmfUpgradeProcedure::switchOver, Starting SI_SWAP thread");
> - swapThread->start();
> + if (!SmfSwapThread::running()) {
> + TRACE("SmfUpgradeProcedure::switchOver: Create the restart 
> indicator");
> + 
> SmfCampaignThread::instance()->campaign()->getUpgradeCampaign()->createSmfRestartIndicator();
> +
> + SmfSwapThread *swapThread = new SmfSwapThread(this);
> + TRACE("SmfUpgradeProcedure::switchOver, Starting SI_SWAP 
> thread");
> + swapThread->start();
> + } else {
> + TRACE("SmfUpgradeProcedure::switchOver, SI_SWAP thread already 
> running");
> + SmfSwapThread::setProc(this);
> +
> + }
>   
>   TRACE_LEAVE();
>   }
> @@ -4156,6 +4162,31 @@ SmfUpgradeProcedure::resetProcCounter()
>   /*  Static methods*/
>   /**/
>   
> +SmfSwapThread *SmfSwapThread::me(0);
> +std::mutex SmfSwapThread::m_mutex;
> +
> +/**
> + * SmfSmfSwapThread::running
> + * Is the thread currently running?
> + */
> +bool
> +SmfSwapThread::running(void)
> +{
> + std::lock_guard guard(m_mutex);
> + 

Re: [devel] [PATCH 1 of 1] imm: Also do not send ccb abort reply to clients if the CCBs are in EMPTY state [#2010]

[Neelakanta Reddy]

Hi Hung,

Reviewed the patch.
Ack.

/Neel.

On 2016/10/06 02:13 PM, Hung Nguyen wrote:
>   osaf/services/saf/immsv/immnd/ImmModel.cc |  3 ++-
>   1 files changed, 2 insertions(+), 1 deletions(-)
>
>
> Also do not send ccb abort reply to clients if the CCBs are in EMPTY state.
>
> diff --git a/osaf/services/saf/immsv/immnd/ImmModel.cc 
> b/osaf/services/saf/immsv/immnd/ImmModel.cc
> --- a/osaf/services/saf/immsv/immnd/ImmModel.cc
> +++ b/osaf/services/saf/immsv/immnd/ImmModel.cc
> @@ -6155,7 +6155,8 @@ ImmModel::ccbAbort(SaUint32T ccbId, Conn
>   }
>   
>   /* Only send response when ccb continuation is not purged */
> -if (!ccb->mPurged && ccb->mState != IMM_CCB_READY && ccb->mState != 
> IMM_CCB_VALIDATED) {
> +if (!ccb->mPurged && ccb->mState != IMM_CCB_EMPTY
> +&& ccb->mState != IMM_CCB_READY && ccb->mState != 
> IMM_CCB_VALIDATED) {
>   clVector.push_back(ccb->mOriginatingConn);
>   *nodeId = ccb->mOriginatingNode;
>   }


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

Re: [devel] [PATCH 0 of 1] Review Request for smf: balanced upgrade software bundle missmatch [#2080]

[Neelakanta Reddy]

Hi Rafel,

Reviewed the patch.
Ack.

/Neel.

On 2016/09/29 01:56 PM, Rafael Odzakow wrote:
> Summary: smf: balanced upgrade software bundle missmatch [#2080]
> Review request for Trac Ticket(s): #2080
> Peer Reviewer(s): lennart, reddy
> Pull request to: <>
> Affected branch(es): 5.1.x
> Development branch: <>
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>   <>
>
> changeset 12f0f4b6bc10533a310a879ad68e490a288c3bb8
> Author:   Rafael Odzakow 
> Date: Thu, 29 Sep 2016 10:08:42 +0200
>
>   smf: balanced upgrade software bundle missmatch [#2080]
>
>   When merging steps for the BALANCED_MODE execution there is a missmatch 
> in
>   how the software bundles are added to the new step. The problem will 
> show
>   when nodes have different software installed and not all of those nodes 
> are
>   included in the balanced list.
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfExecControl.cc |  9 +++--
>   1 files changed, 3 insertions(+), 6 deletions(-)
>
>
> Testing Commands:
> -
>   <>
>
>
> Testing, Expected Results:
> --
>   <>
>
>
> Conditions of Submission:
> -
>   <>
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 0 of 1] Review Request for imm: Set validation abort error string when OI returns ERR_BAD_OPERATION or ERR_FAILED_OPERATION [#1650]

[Neelakanta Reddy]

Hi Hung,

Reviewed and tested the patch.
Ack.

/Neel.

On 2016/09/29 01:18 PM, Hung Nguyen wrote:
> Summary: imm: Set validation abort error string when OI returns 
> ERR_BAD_OPERATION or ERR_FAILED_OPERATION [#1650]
> Review request for Trac Ticket(s): 1650
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.0, 5.1, 5.2
> Development branch: 5.2
>
> 
> 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 c3d087ae2dcb8a6aa9b1e6fc79922ef8d70cfbe2
> Author:   Hung Nguyen 
> Date: Thu, 29 Sep 2016 11:15:50 +0700
>
>   imm: Set validation abort error string when OI returns 
> ERR_BAD_OPERATION or
>   ERR_FAILED_OPERATION [#1650]
>
>   Set validation abort error string when OI returns ERR_BAD_OPERATION or
>   ERR_FAILED_OPERATION. This is to prevent om clients from retrying the
>   operations that are already rejected by OI.
>
>
> Complete diffstat:
> --
>   osaf/services/saf/immsv/immnd/ImmModel.cc |  18 +++---
>   osaf/services/saf/immsv/immnd/immnd_evt.c |  82 
> ++
>   2 files changed, 37 insertions(+), 63 deletions(-)
>
>
> Testing Commands:
> -
>
>
>
> Testing, Expected Results:
> --
>
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 0 of 1] Review Request for smf: Recreate IMM handles if bad handle when deleting node group [#2046]

[Neelakanta Reddy]

Hi Leenart,

Reviewed the patch.
Ack.

/Neel.

On 2016/09/29 06:15 PM, Lennart Lund wrote:
> Summary: smf: Recreate IMM handles if bad handle when deleting node group
> Review request for Trac Ticket(s): #2046
> Peer Reviewer(s): reddy.neelaka...@oracle.com, rafael.odza...@ericsson.com
> Pull request to: <>
> Affected branch(es): <>
> Development branch: <>
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>   <>
>
> changeset 5092586880b8ee951502d59badb5d8c397b0916e
> Author:   Lennart Lund 
> Date: Thu, 29 Sep 2016 14:31:35 +0200
>
>   smf: Recreate IMM handles if bad handle when deleting node group [#2046]
>
>   Fix the deleteNodeGroup() method must be so that if the delete operation
>   fails with bad handles new handles are created so that the node group 
> can be
>   deleted
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  93 
> +
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh |   3 +-
>   2 files changed, 67 insertions(+), 29 deletions(-)
>
>
> Testing Commands:
> -
>   <>
>
>
> Testing, Expected Results:
> --
>   <>
>
>
> Conditions of Submission:
> -
> Ack by reviewers
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 0 of 1] Review Request for smf: Delete node group if already exist when creating [#2049]

[Neelakanta Reddy]

Hi Leenart,

Reviewed the patch.
Ack.

/Neel.

On 2016/09/29 06:11 PM, Lennart Lund wrote:
> Summary: smf: Delete node group if already exist when creating
> Review request for Trac Ticket(s): #2049
> Peer Reviewer(s): reddy.neelaka...@oracle.com, rafael.odza...@ericsson.com
> Pull request to: <>
> Affected branch(es): <>
> Development branch: <>
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>   <>
>
> changeset c680b5ad6c35b1ffcdfa9e563f1f32b3f3cc8e36
> Author:   Lennart Lund 
> Date: Thu, 29 Sep 2016 14:23:33 +0200
>
>   smf: Delete node group if already exist when creating [#2049]
>
>   If a node group for admin operation already exist when create is done 
> the
>   existing group shall be deleted so that the new group can be created
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  76 
> +---
>   1 files changed, 49 insertions(+), 27 deletions(-)
>
>
> Testing Commands:
> -
>   <>
>
>
> Testing, Expected Results:
> --
>   <>
>
>
> Conditions of Submission:
> -
> Ack from reviewers
>
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  n  n
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 1 of 1] smf: Delete node group if already exist when creating [#2049]

[Neelakanta Reddy]

Hi Leenart,

returning of ERR_EXIST is very rare, and not as frequent as BAD_HANDLE.
Still, not satisfied with infinite loop, without finite re-trys.

Ack from me.

Thanks,
Neel.

On 2016/09/27 05:14 PM, Lennart Lund wrote:
> Hi Neel
>
> See my comments/answer tagged [Lennart]
>
> Thanks
> Lennart
>
>> -Original Message-
>> From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
>> Sent: den 27 september 2016 11:21
>> To: Lennart Lund <lennart.l...@ericsson.com>; Rafael Odzakow
>> <rafael.odza...@ericsson.com>
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [PATCH 1 of 1] smf: Delete node group if already exist when
>> creating [#2049]
>>
>> Hi Lennart,
>>
>> Reviewed the patch. Following are the comments:
>>
>> 1. Do not use infinite loops like while(true),  In this case while loop
>> is not required.
> [Lennart] I have chosen to use a loop since 
> immutil_saImmOmCcbObjectCreate_2() may have to be called more than once
> See also my answers for ticket #2046. The condition for this loop to continue 
> is SA_AIS_ERR_EXIST (in #2046 it's SA_AIS_ERR_BAD_HANDLE) otherwise the 
> mechanism is the same.
>
>> 2. comments inline.
>>
>> Thanks,
>> Neel.
>>
>>
>> On 2016/09/22 08:34 PM, Lennart Lund wrote:
>>>osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  51
>> -
>>>1 files changed, 33 insertions(+), 18 deletions(-)
>>>
>>>
>>> If a node group for admin operation already exist when create is done the
>>> existing group shall be deleted so that the new group can be created
>>>
>>> diff --git a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
>> b/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
>>> --- a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
>>> +++ b/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
>>> @@ -3537,24 +3537,39 @@ bool SmfAdminOperation::createNodeGroup(
>>>
>>> // 
>>> // Create the node group
>>> -   m_errno = immutil_saImmOmCcbObjectCreate_2(
>>> -   m_ccbHandle,
>>> -   className,
>>> -   ,
>>> -   attrValues);
>>> -
>>> -   if (m_errno != SA_AIS_OK) {
>>> -   LOG_NO("%s: saImmOmCcbObjectCreate_2() '%s' Fail %s",
>>> -   __FUNCTION__, nGnodeName,
>> saf_error(m_errno));
>>> -   rc = false;
>>> -   } else {
>>> -   m_errno = saImmOmCcbApply(m_ccbHandle);
>>> -   if (m_errno != SA_AIS_OK) {
>>> -   LOG_NO("%s: saImmOmCcbApply() Fail '%s'",
>>> -   __FUNCTION__, saf_error(m_errno));
>>> -   rc = false;
>>> -   }
>>> -   }
>>> +while (true) {
>>> +m_errno = immutil_saImmOmCcbObjectCreate_2(
>>> +m_ccbHandle,
>>> +className,
>>> +,
>>> +attrValues);
>>> +
>>> +if (m_errno == SA_AIS_ERR_EXIST) {
>>> +// A node group with the same name already exist
>>> +// May happen if delete after usage has failed
>>> +bool rc = deleteNodeGroup();
>>> +if (rc == false) {
>>> +LOG_NO("%s: deleteNodeGroup() Fail",
>>> +   __FUNCTION__);
>>> +break;
>>> +}
>> in the else codition, if deleteNodeGroup is true call
>> immutil_saImmOmCcbObjectCreate_2. In deleteNodeGroup there are
>> retries
>> for deleting.
>> No need to have while loop,
> [Lennart] I have chosen to use a loop instead of a sequence that has a call 
> of immutil_saImmOmCcbObjectCreate_2() in two places.
> This solution also encapsulates all saImmOmCcbObjectCreate_2 handling 
> including deleting if needed and the error handling
>>> +continue;
>>> +}
>>> +if (m_errno != SA_AIS_OK) {
>>> +LOG_NO("%s: saImmOmCcbObjectCreate_2() '%s' Fail 
>>> %s",
>>> +__FUNCTION__, nGnodeName, 
>>> saf_error(m_errno));
>>> +rc = false;
>>> +break;
>>> +} else {
>>> +m_errno = saImmOmCcbApply(m_ccbHandle);
>>> +if (m_errno != SA_AIS_OK) {
>>> +LOG_NO("%s: saImmOmCcbApply() Fail '%s'",
>>> +__FUNCTION__, saf_error(m_errno));
>>> +rc = false;
>>> +}
>>> +break;
>>> +}
>>> +}
>>>
>>> if (nodeName != NULL)
>>> free(nodeName);


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

Re: [devel] [PATCH 1 of 1] smf: Recreate IMM handles if bad handle when deleting node group [#2046]

[Neelakanta Reddy]

Hi Lennart,

comments inline.

On 2016/09/27 04:58 PM, Lennart Lund wrote:
> Hi Neel,
>
> See my comments/answers inline [Lennart]
>
> Thanks
> Lennart
>
>> -Original Message-
>> From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com]
>> Sent: den 27 september 2016 11:04
>> To: Lennart Lund <lennart.l...@ericsson.com>; Rafael Odzakow
>> <rafael.odza...@ericsson.com>
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [PATCH 1 of 1] smf: Recreate IMM handles if bad handle when
>> deleting node group [#2046]
>>
>> Hi Lennart,
>>
>> Reviewed the patch, I have to NACK the patch because of the comments.
>>
>> Following are the comments:
>>
>> 1. The retries can not be infinite, while(1) has to be changed to some
>> finite number of retries.
> [Lennart] Since immutil_saImmOmCcbObjectDelete() may have to be called more 
> than once I have chosen to use a loop.
> The loop is not infinite but the loop is not ended because of a loop counter 
> and the exit condition is not tested within the while parenthesis. The loop 
> continues only if immutil_saImmOmCcbObjectDelete returns 
> SA_AIS_ERR_BAD_HANDLE. Before the loop continues new handles are requested 
> but if this fails the loop will end.
> The loop will be infinite only if it is possible to create handles (no Fail) 
> and saImmOmCcbObjectDelete always returns SA_AIS_ERR_BAD_HANDLE even if new 
> handles just have been successfully created. If you think this could happen I 
> can insert a loop counter to end the loop in case?
[Neel]
BAD_HANDLE will not be returned always.  But the loop should not be 
infinite.
>> 2.  make saImmOiFinalize as part of getAllImmHandles. (for more
>> information look into avd_imm_reinit_bg_thread in
>> osaf/services/saf/amf/amfd/imm.cc)
> [Lennart] This is not an OI it's an object manager. In this case 
> immutil_saImmOmFinalize() is called before the attempt to create new handles. 
> However it is not done in the getAllImmHandles() function. This function is 
> also used to create the handles in the constructor and if this fails none of 
> the admin operations will be executed (campaign will fail)
[Neel]
you can guard this with immhandle, if it is zero or NULL do not 
finalize, this is to generalize and not a mandatory change.


>
>> 3.  for each retry there must be sleep.
> [Lennart] Note that this is not a loop for handling SA_AIS_ERR_TRY_AGAIN this 
> is handled within the immutil_xxx functions. A sleep is not needed here since 
> there is no attempt made to call immutil_saImmOmCcbObjectDelete() again until 
> after both OM Finalize and creation of new handles is done
[Neel]
even though it is not TRY_AGAIN, for each retry there must be a sleep,  
for any type of error, because this will  give system/openSAF to do some 
initializations, instead of returning the same error again..
This has been done in AMF (AMF is well tested with BAD_HANDLE from IMM 
perspective):

  if (rc == SA_AIS_ERR_BAD_HANDLE) {
 osaf_nanosleep();


Thanks,
Neel.
>> Regards,
>> Neel.
>>
>>
>> On 2016/09/22 07:03 PM, Lennart Lund wrote:
>>>osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  49
>> +
>>>1 files changed, 33 insertions(+), 16 deletions(-)
>>>
>>>
>>> Fix the deleteNodeGroup() method must be so that if the delete operation
>> fails
>>> with bad handles new handles are created so that the node group can be
>> deleted
>>> diff --git a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
>> b/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
>>> --- a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
>>> +++ b/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc
>>> @@ -3580,22 +3580,36 @@ bool SmfAdminOperation::deleteNodeGroup(
>>> );
>>>
>>> TRACE("\t Deleting nodeGroup '%s'", nodeGroupName_s.c_str());
>>> -
>>> -   m_errno = immutil_saImmOmCcbObjectDelete(m_ccbHandle,
>>> -   );
>>> -   if (m_errno != SA_AIS_OK) {
>>> -   LOG_NO("%s: saImmOmCcbObjectDelete '%s' Fail %s",
>>> -__FUNCTION__, nodeGroupName_s.c_str(),
>>> -saf_error(m_errno));
>>> -   rc = false;
>>> -   } else {
>>> -   m_errno = saImmOmCcbApply(m_ccbHandle);
>>> -   if (m_errno != SA_AIS_OK) {
>>> -   LOG_NO("%s: saImmOmCcbApply() Fail '%s'",
>>> -   __FUNCTION__, saf_error(m_errno));
>>> -   rc = false;
>>> -   }
>>> -   }
>>>