Re: [devel] [PATCH 1/1] smf: SMF created a CCB to create smfRollbackElement object, but CCB was aborted due to IMM [#2676]

[Rafael Odzakow]

Resending my question. Also to be clear, the retry loops are nested, it does 
not seem there is a reason for it.

On mån, 2017-11-27 at 15:36 +0100, Rafael Odzakow wrote:

SmfCampaignWrapup::executeCampComplete()  is calling SmfImmCcbAction. So looks 
like a double retry spread out across two classes. Why not have the retries in  
SmfImmCcbAction::execute only?


On 11/17/2017 07:12 AM, Vijay Roy wrote:

Hi Rafael,



We need the while loop in “SmfCampaignWrapup::executeCampComplete()” as we 
encountered the issue at Wrapup too while testing.



Thanks

Vijay





-Original Message-
From: Rafael Odzakow [mailto:rafael.odza...@ericsson.com]
Sent: Thursday, November 16, 2017 8:54 PM
To: Vijay Roy <vijay@oracle.com><mailto:vijay@oracle.com>
Cc: 
opensaf-devel@lists.sourceforge.net<mailto:opensaf-devel@lists.sourceforge.net>;
 Lennart Lund <lennart.l...@ericsson.com><mailto:lennart.l...@ericsson.com>
Subject: Re: [PATCH 1/1] smf: SMF created a CCB to create smfRollbackElement 
object, but CCB was aborted due to IMM [#2676]



What about the added while loops in

SmfCampaignWrapup::executeCampComplete() should they be removed now with this 
addition?





On 11/16/2017 10:44 AM, Vijay Roy wrote:

> Handling ERROR_EXIST in smfRollbackElement creation and handling

> TRY_AGAIN in immCCBOperations.

> ---

>   src/smf/smfd/SmfUpgradeAction.cc | 26 +++---

>   1 file changed, 19 insertions(+), 7 deletions(-)

>

> diff --git a/src/smf/smfd/SmfUpgradeAction.cc

> b/src/smf/smfd/SmfUpgradeAction.cc

> index 94c3dfd..af75cd7 100644

> --- a/src/smf/smfd/SmfUpgradeAction.cc

> +++ b/src/smf/smfd/SmfUpgradeAction.cc

> @@ -28,6 +28,7 @@

>   #include "smf/smfd/SmfUtils.h"

>   #include "smfd.h"

>   #include "smf/smfd/SmfTargetTemplate.h"

> +#include "base/time.h"

>

>   /* 

>*   DEFINITIONS

> @@ -460,6 +461,7 @@ SaAisErrorT SmfImmCcbAction::execute(SaImmOiHandleT 
> i_oiHandle,

>const std::string* i_rollbackDn) {

> SaAisErrorT result = SA_AIS_OK;

> SmfRollbackCcb* rollbackCcb = NULL;

> +  base::Timer doImmOpTimer(6);

>

> TRACE_ENTER();

>

> @@ -473,8 +475,8 @@ SaAisErrorT SmfImmCcbAction::execute(SaImmOiHandleT 
> i_oiHandle,

>   immRollbackCcbDn += ",";

>   immRollbackCcbDn += *i_rollbackDn;

>

> -if ((result = smfCreateRollbackElement(immRollbackCcbDn, i_oiHandle)) !=

> -SA_AIS_OK) {

> +result = smfCreateRollbackElement(immRollbackCcbDn, i_oiHandle);

> +if ((result != SA_AIS_OK) && (result != SA_AIS_ERR_EXIST)) {

> LOG_ER(

> "SmfImmCcbAction::execute failed to create rollback element %s, 
> rc=%s",

> immRollbackCcbDn.c_str(), saf_error(result)); @@ -490,11

> +492,21 @@ SaAisErrorT SmfImmCcbAction::execute(SaImmOiHandleT i_oiHandle,

> }

>

> if (m_operations.size() > 0) {

> -SmfImmUtils immUtil;

> -if ((result = immUtil.doImmOperations(m_operations, rollbackCcb)) !=

> -SA_AIS_OK) {

> -  delete rollbackCcb;

> -  rollbackCcb = NULL;

> +

> +doImmOpTimer.set_timeout_time(6);

> +while (doImmOpTimer.is_timeout() == false) {

> +  SmfImmUtils immUtil;

> +  result = immUtil.doImmOperations(m_operations, rollbackCcb);

> +  if (result == SA_AIS_ERR_TRY_AGAIN) {

> + base::Sleep(base::kFiveHundredMilliseconds);

> + continue;

> +  } else if (result != SA_AIS_OK) {

> + LOG_WA("%s: SmfImmCcbAction:execute Fail '%s'",

> + __FUNCTION__, saf_error(result));

> + delete rollbackCcb;

> + rollbackCcb = NULL;

> +  }

> +  break;

>   }

> }

>





--
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: Add MDS logging to smfd and smfnd [#2722]

[Rafael Odzakow]

ACK

On fre, 2017-12-01 at 16:13 +0100, Lennart Lund wrote:
> Summary: smf: Add MDS logging to smfd and smfnd [#2722]
> Review request for Ticket(s): 2722
> Peer Reviewer(s): rafael.odza...@ericsson.com
> Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
> Affected branch(es): develop
> Development branch: ticket-2722
> Base revision: d40172a1afb2f95afdb6b6b5cf4804d559ac6c50
> Personal repository: git://git.code.sf.net/u/elunlen/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):
> -
> *** EXPLAIN/COMMENT THE PATCH SERIES HERE ***
> 
> revision 69653a7b4c6fe9863d3b04d938f20eccc93092aa
> Author:   Lennart Lund 
> Date: Fri, 1 Dec 2017 15:58:00 +0100
> 
> smf: Add MDS logging to smfd and smfnd [#2722]
> 
> Add syslogs to smfd and smfnd to log MDS handling so that
> initializing, role
> change MDS events etc. All of these logs will be tagged with 'MDS '
> to make
> it possible to grep. There will be a number of new logs added to
> syslog but
> all of these logs will only be written at special occasions like
> start up,
> service down / up etc.
> 
> 
> 
> Complete diffstat:
> --
>  src/smf/smfd/smfd_amf.cc   |  2 ++
>  src/smf/smfd/smfd_main.cc  |  5 -
>  src/smf/smfd/smfd_mds.c| 35 +++
>  src/smf/smfnd/smfnd_main.c |  1 +
>  src/smf/smfnd/smfnd_mds.c  | 18 ++
>  5 files changed, 48 insertions(+), 13 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 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 

Re: [devel] [PATCH 1/1] smf: SMF created a CCB to create smfRollbackElement object, but CCB was aborted due to IMM [#2676]

[Rafael Odzakow]

SmfCampaignWrapup::executeCampComplete()  is calling SmfImmCcbAction. So 
looks like a double retry spread out across two classes. Why not have 
the retries in  SmfImmCcbAction::execute only?




On 11/17/2017 07:12 AM, Vijay Roy wrote:


Hi Rafael,

We need the while loop in “SmfCampaignWrapup::executeCampComplete()” 
as we encountered the issue at Wrapup too while testing.


Thanks

Vijay

-Original Message-
From: Rafael Odzakow [mailto:rafael.odza...@ericsson.com]
Sent: Thursday, November 16, 2017 8:54 PM
To: Vijay Roy <vijay@oracle.com>
Cc: opensaf-devel@lists.sourceforge.net; Lennart Lund 
<lennart.l...@ericsson.com>
Subject: Re: [PATCH 1/1] smf: SMF created a CCB to create 
smfRollbackElement object, but CCB was aborted due to IMM [#2676]


What about the added while loops in

SmfCampaignWrapup::executeCampComplete() should they be removed now 
with this addition?


On 11/16/2017 10:44 AM, Vijay Roy wrote:

> Handling ERROR_EXIST in smfRollbackElement creation and handling

> TRY_AGAIN in immCCBOperations.

> ---

>   src/smf/smfd/SmfUpgradeAction.cc | 26 +++---

>   1 file changed, 19 insertions(+), 7 deletions(-)

>

> diff --git a/src/smf/smfd/SmfUpgradeAction.cc

> b/src/smf/smfd/SmfUpgradeAction.cc

> index 94c3dfd..af75cd7 100644

> --- a/src/smf/smfd/SmfUpgradeAction.cc

> +++ b/src/smf/smfd/SmfUpgradeAction.cc

> @@ -28,6 +28,7 @@

>   #include "smf/smfd/SmfUtils.h"

>   #include "smfd.h"

>   #include "smf/smfd/SmfTargetTemplate.h"

> +#include "base/time.h"

>

>   /* 



>    *   DEFINITIONS

> @@ -460,6 +461,7 @@ SaAisErrorT 
SmfImmCcbAction::execute(SaImmOiHandleT i_oiHandle,


> const std::string* i_rollbackDn) {

> SaAisErrorT result = SA_AIS_OK;

> SmfRollbackCcb* rollbackCcb = NULL;

> +  base::Timer doImmOpTimer(6);

>

> TRACE_ENTER();

>

> @@ -473,8 +475,8 @@ SaAisErrorT 
SmfImmCcbAction::execute(SaImmOiHandleT i_oiHandle,


>   immRollbackCcbDn += ",";

>   immRollbackCcbDn += *i_rollbackDn;

>

> -    if ((result = smfCreateRollbackElement(immRollbackCcbDn, 
i_oiHandle)) !=


> -    SA_AIS_OK) {

> +    result = smfCreateRollbackElement(immRollbackCcbDn, i_oiHandle);

> +    if ((result != SA_AIS_OK) && (result != SA_AIS_ERR_EXIST)) {

> LOG_ER(

> "SmfImmCcbAction::execute failed to create rollback element %s, rc=%s",

> immRollbackCcbDn.c_str(), saf_error(result)); @@ -490,11

> +492,21 @@ SaAisErrorT SmfImmCcbAction::execute(SaImmOiHandleT 
i_oiHandle,


> }

>

> if (m_operations.size() > 0) {

> -    SmfImmUtils immUtil;

> -    if ((result = immUtil.doImmOperations(m_operations, 
rollbackCcb)) !=


> -    SA_AIS_OK) {

> -  delete rollbackCcb;

> -  rollbackCcb = NULL;

> +

> + doImmOpTimer.set_timeout_time(6);

> +    while (doImmOpTimer.is_timeout() == false) {

> +  SmfImmUtils immUtil;

> +  result = immUtil.doImmOperations(m_operations, rollbackCcb);

> +  if (result == SA_AIS_ERR_TRY_AGAIN) {

> + base::Sleep(base::kFiveHundredMilliseconds);

> + continue;

> +  } else if (result != SA_AIS_OK) {

> + LOG_WA("%s: SmfImmCcbAction:execute Fail '%s'",

> + __FUNCTION__, saf_error(result));

> + delete rollbackCcb;

> + rollbackCcb = NULL;

> +  }

> +  break;

>   }

> }

>



--
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: SMF cannot distinguish swAdd and swRemove in same procedure [#2675]

[Rafael Odzakow]

ACK, tested.


On 11/24/2017 06:53 AM, Vijay Roy wrote:


Hi Rafael,

Are you confirming that issue reported got tested over path 2765?

If so, Please provide acknowledgement for the fix/patch.

Thanks

Vijay

*From:*Rafael Odzakow [mailto:rafael.odza...@ericsson.com]
*Sent:* Thursday, November 23, 2017 5:12 PM
*To:* Syam Prasad Talluri <syam.tall...@oracle.com>; Vijay Roy 
<vijay@oracle.com>
*Cc:* Ravi Sekhar Reddy Konda <ravisekhar.ko...@oracle.com>; Srinivas 
Mangipudy <srinivas.mangip...@oracle.com>; Lennart Lund 
<lennart.l...@ericsson.com>
*Subject:* Re: [PATCH 1/1] smf: SMF cannot distinguish swAdd and 
swRemove in same procedure [#2675]



Ran the campaigns on a branch that contained 2675 patch. It is tested 
here now at least :)


On 11/23/2017 09:04 AM, Syam Prasad Talluri wrote:

Rafael,

We are able to reproduced the issue with your campaigns.

1.When I execute using install campaign, we are able to see the
below logs in both SC-1 and SC-2

*logger: BundleB_online_install*

*logger: BundleB_offline_install *

**

2.When we try using the upgrade campaigns, we are not able to see
any logs either in SC’s and PL’s.

If SwAdd and SwRemove are added in same procedure with same Bundle
name then those are removed from both the lists,  So either
installation nor remove will not happen.

Traces captured as part of reproducing bug is added below.

Nov 23 11:55:49.447514 osafsmfd
[3902:4132:src/smf/smfd/SmfUpgradeMethod.cc:0183] TR
SmfUpgradeScope::removeSwAddRemoveDuplicates():
*Bundle=safSmfBundle=BundleB found in  and 
within a procedure, remove from both lists*

Nov 23 11:55:49.447524 osafsmfd
[3902:4132:src/smf/smfd/SmfUpgradeMethod.cc:0205] >>
removeSwAddRemoveDuplicate

Nov 23 11:55:49.447530 osafsmfd
[3902:4132:src/smf/smfd/SmfUpgradeMethod.cc:0211] TR
SmfUpgradeScope::removeSwAddRemoveDuplicate*(): erase element
"safSmfBundle=BundleB"*

Nov 23 11:55:49.447537 osafsmfd
[3902:*4132*:src/smf/smfd/SmfUpgradeMethod.cc:0218] <<
removeSwAddRemoveDuplicate

Nov 23 11:55:49.447542 osafsmfd
[3902:4132:src/smf/smfd/SmfUpgradeMethod.cc:0205] >>
removeSwAddRemoveDuplicate

Nov 23 11:55:49.447548 osafsmfd
[3902:4132:src/smf/smfd/SmfUpgradeMethod.cc:0211] TR
SmfUpgradeScope::removeSwAddRemoveDuplicate*(): erase element
"safSmfBundle=BundleB"*

Thanks,

Syam.

*From:*Rafael Odzakow [mailto:rafael.odza...@ericsson.com]
*Sent:* Monday, November 20, 2017 8:45 PM
*To:* Vijay Roy <vijay@oracle.com> <mailto:vijay@oracle.com>
*Cc:* Ravi Sekhar Reddy Konda <ravisekhar.ko...@oracle.com>
<mailto:ravisekhar.ko...@oracle.com>; Syam Prasad Talluri
<syam.tall...@oracle.com> <mailto:syam.tall...@oracle.com>;
Srinivas Mangipudy <srinivas.mangip...@oracle.com>
<mailto:srinivas.mangip...@oracle.com>; Lennart Lund
<lennart.l...@ericsson.com> <mailto:lennart.l...@ericsson.com>
*Subject:* Re: [PATCH 1/1] smf: SMF cannot distinguish swAdd and
swRemove in same procedure [#2675]

I could not reproduce this issue, I do not have the bundle that
should be connected to these campaigns so I stripped the campaign
down and added my own.

As far as I could see the campaigns did the correct thing and the
bundle was removed from SC-1,SC-2 and added to PL-3,PL-4. I have
attached the modified campaigns.

On 11/17/2017 07:07 AM, Vijay Roy wrote:

Hi Rafael,

Attached the campaign xml’s for reference.

*_Core issue:_*

**

1.By using attached install_campaign.xml we have installed
software on 2 SC’s

2.Later by using attached upgrade_campaign.xml we tried to
remove the same software on 2 SC’s and Install the same on 2
PL’s.

For this we have added one swAdd with PL’s and swRemove with SC’s.

*Issue*: In current code under one procedure If we add and
remove same software we will only remove the software (but not
add).  Instead of comparing the AMF nodes in both the tags the
current code is validating only BundleDN.

*Code Fix*: We are comparing the AmfNodes inside the swAdd and
swRemove tags and make decision to remove or add software wisely.

Thanks

Vijay

-Original Message-
From: Rafael Odzakow [mailto:rafael.odza...@ericsson.com]
Sent: Thursday, November 16, 2017 8:05 PM
To: Vijay Roy <vijay@oracle.com> <mailto:vijay@oracle.com>
Cc: opensaf-devel@lists.sourceforge.net
<mailto:opensaf-devel@lists.sourceforge.net>
Subject: Re: [PATCH 1/1] smf: SMF cannot distinguish swAdd and
swRemove in same procedure [#2675]

I do not understand the issue, pleas

Re: [devel] [PATCH 1/1] smf: SMF created a CCB to create smfRollbackElement object, but CCB was aborted due to IMM [#2676]

[Rafael Odzakow]

What about the added while loops in 
SmfCampaignWrapup::executeCampComplete() should they be removed now with 
this addition?



On 11/16/2017 10:44 AM, Vijay Roy wrote:

Handling ERROR_EXIST in smfRollbackElement creation and
handling TRY_AGAIN in immCCBOperations.
---
  src/smf/smfd/SmfUpgradeAction.cc | 26 +++---
  1 file changed, 19 insertions(+), 7 deletions(-)

diff --git a/src/smf/smfd/SmfUpgradeAction.cc b/src/smf/smfd/SmfUpgradeAction.cc
index 94c3dfd..af75cd7 100644
--- a/src/smf/smfd/SmfUpgradeAction.cc
+++ b/src/smf/smfd/SmfUpgradeAction.cc
@@ -28,6 +28,7 @@
  #include "smf/smfd/SmfUtils.h"
  #include "smfd.h"
  #include "smf/smfd/SmfTargetTemplate.h"
+#include "base/time.h"
  
  /* 

   *   DEFINITIONS
@@ -460,6 +461,7 @@ SaAisErrorT SmfImmCcbAction::execute(SaImmOiHandleT 
i_oiHandle,
   const std::string* i_rollbackDn) {
SaAisErrorT result = SA_AIS_OK;
SmfRollbackCcb* rollbackCcb = NULL;
+  base::Timer doImmOpTimer(6);
  
TRACE_ENTER();
  
@@ -473,8 +475,8 @@ SaAisErrorT SmfImmCcbAction::execute(SaImmOiHandleT i_oiHandle,

  immRollbackCcbDn += ",";
  immRollbackCcbDn += *i_rollbackDn;
  
-if ((result = smfCreateRollbackElement(immRollbackCcbDn, i_oiHandle)) !=

-SA_AIS_OK) {
+result = smfCreateRollbackElement(immRollbackCcbDn, i_oiHandle);
+if ((result != SA_AIS_OK) && (result != SA_AIS_ERR_EXIST)) {
LOG_ER(
"SmfImmCcbAction::execute failed to create rollback element %s, 
rc=%s",
immRollbackCcbDn.c_str(), saf_error(result));
@@ -490,11 +492,21 @@ SaAisErrorT SmfImmCcbAction::execute(SaImmOiHandleT 
i_oiHandle,
}
  
if (m_operations.size() > 0) {

-SmfImmUtils immUtil;
-if ((result = immUtil.doImmOperations(m_operations, rollbackCcb)) !=
-SA_AIS_OK) {
-  delete rollbackCcb;
-  rollbackCcb = NULL;
+
+doImmOpTimer.set_timeout_time(6);
+while (doImmOpTimer.is_timeout() == false) {
+  SmfImmUtils immUtil;
+  result = immUtil.doImmOperations(m_operations, rollbackCcb);
+  if (result == SA_AIS_ERR_TRY_AGAIN) {
+ base::Sleep(base::kFiveHundredMilliseconds);
+ continue;
+  } else if (result != SA_AIS_OK) {
+ LOG_WA("%s: SmfImmCcbAction:execute Fail '%s'",
+ __FUNCTION__, saf_error(result));
+ delete rollbackCcb;
+ rollbackCcb = NULL;
+  }
+  break;
  }
}
  



--
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: SMF cannot distinguish swAdd and swRemove in same procedure [#2675]

[Rafael Odzakow]

I do not understand the issue, please provide a campaign that would case 
the ambiguity between nodes.



On 11/16/2017 10:18 AM, Vijay Roy wrote:

Conditional check on AMF nodes in swadd and swRemove exactly for same and match 
to avoid ambiguity between nodes.
---
  src/smf/smfd/SmfUpgradeMethod.cc | 21 -
  1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/src/smf/smfd/SmfUpgradeMethod.cc b/src/smf/smfd/SmfUpgradeMethod.cc
index 0149c93..3671d80 100644
--- a/src/smf/smfd/SmfUpgradeMethod.cc
+++ b/src/smf/smfd/SmfUpgradeMethod.cc
@@ -173,11 +173,30 @@ void SmfUpgradeScope::removeSwAddRemoveDuplicates(
std::set toBeRemoved;
  
// Find out which bundles are specified in both swAdd and SwRemove.

-  // Create a set of DN, since the comparison is based on that.
+  // Create a set of DN's if their Amf Nodes in swAdd and swRemove exactly 
same and match.
for (auto  : io_addList) {
+bool sameNodesInAddRemoveSw = false;
  for (auto  : io_removeList) {
const std::string  = elemAdd.getBundleDn();
if (swAddBundleDn == elemRemove.getBundleDn()) {
+ for (auto  : elemAdd.getPlmExecEnvList()) {
+   const std::string& i_addNodeDn = itAdd.getAmfNode();
+ for (auto itRemove : elemRemove.getPlmExecEnvList()) {
+   const std::string& i_removeNodeDn = itRemove.getAmfNode();
+   if (i_addNodeDn == i_removeNodeDn) {
+ sameNodesInAddRemoveSw = true;
+ TRACE("SmfUpgradeScope::removeSwAddRemoveDuplicates(): node DN's 
%s are same ", i_addNodeDn.c_str());
+ break;
+   }
+ }
+ if (sameNodesInAddRemoveSw == false) {
+   break;
+ }
+ }
+ if (sameNodesInAddRemoveSw == false) {
+   continue;
+ }
+
  TRACE(
  "SmfUpgradeScope::removeSwAddRemoveDuplicates(): Bundle=%s found in  
and  within a procedure, remove from both lists\n",
  swAddBundleDn.c_str());



--
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] smfd: after cluster reboot, don't re-execute a campaign which has already completed [#2648]

[Rafael Odzakow]

NACK

I bumped into a  issue.


1. start a campaign

2. complete campaign (not commited yet)

3. cluster reboot or opensafd restart on all nodes

4. rollback for campaign fails with:

    osafsmfd[1288]: ER Failed to rollback campaign, campaign not executing



On 10/31/2017 12:46 PM, Lennart Lund wrote:

Ack

Thanks
Lennart


-Original Message-
From: Alex Jones [mailto:alex.jo...@genband.com]
Sent: den 25 oktober 2017 20:21
To: vijay@oracle.com; Lennart Lund <lennart.l...@ericsson.com>;
Rafael Odzakow <rafael.odza...@ericsson.com>
Cc: opensaf-devel@lists.sourceforge.net; Alex Jones
<alex.jo...@genband.com>
Subject: [PATCH 1/1] smfd: after cluster reboot, don't re-execute a campaign
which has already completed [#2648]

smfd crashes after cluster reboot when campaign has completed but not
been committed

When the cluster is coming back up, and smfd gets active assignment,
it will immediately start executing the campaign. If the other SC is
not up yet, and PBE is enabled, then writes to IMM will fail with
NO_RESOURCES, and smfd will crash in updateImmAttr.

Don't re-execute a campaign that has already completed.
---
  src/smf/smfd/SmfCampaign.cc | 4 
  1 file changed, 4 insertions(+)

diff --git a/src/smf/smfd/SmfCampaign.cc b/src/smf/smfd/SmfCampaign.cc
index 6f51483..e3019dc 100644
--- a/src/smf/smfd/SmfCampaign.cc
+++ b/src/smf/smfd/SmfCampaign.cc
@@ -580,6 +580,10 @@ SaAisErrorT SmfCampaign::adminOpVerify(void) {
   * initializes the execution
   */
  SaAisErrorT SmfCampaign::initExecution(void) {
+  // if the campaign has already completed no need to re-execute
+  if (m_cmpgState == SA_SMF_CMPG_EXECUTION_COMPLETED)
+return SA_AIS_OK;
+
// reset the object counter of upgrade procedures (used for procedure OI
// naming)
SmfUpgradeProcedure::resetProcCounter();
--
2.9.5




--
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 2/2] smf: Upgrade nodes without using node group [#2592]

[Rafael Odzakow]

ACK


On 10/23/2017 04:23 PM, Lennart Lund wrote:

Hi Rafael,

* I will fix the name of the constant to follow Google style guide
* Found and fixed the method_rc problem
* I agree that the function should be smaller. However, refactoring have to 
involve
generic abstraction of IMM handling (could be done internally in SMF). The 
problem
here is that complicated IMM API sequences are handled inline and that is 
what makes
the function too long.

I will test and push this now without any more re-reviews.

Thanks
Lennart


-Original Message-
From: Rafael Odzakow
Sent: den 23 oktober 2017 14:29
To: Lennart Lund <lennart.l...@ericsson.com>
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 2/2] smf: Upgrade nodes without using node group
[#2592]

One minor comment inline under [rafael] tag. I had a comment previously
for the nodeGroupAdminOperation function which is not addressed.

[rafael] method_rc seems not to be set (to false) if the
AdminOperationInvoke fails without reaching timeout.


A general comment to big functions with break and continue is that the
flow is too complex to have a overview of. Consider refactoring in the
future.



On 10/19/2017 02:16 PM, Lennart Lund wrote:

Udates after review. This commit will be merged with the fix before push
---
   src/smf/smfd/SmfUpgradeStep.cc | 90 +++

---

   src/smf/smfd/SmfUpgradeStep.h  |  6 +--
   2 files changed, 43 insertions(+), 53 deletions(-)

diff --git a/src/smf/smfd/SmfUpgradeStep.cc

b/src/smf/smfd/SmfUpgradeStep.cc

index 892c32602..25f816485 100644
--- a/src/smf/smfd/SmfUpgradeStep.cc
+++ b/src/smf/smfd/SmfUpgradeStep.cc
@@ -2794,7 +2794,7 @@

SmfAdminOperation::SmfAdminOperation(std::list
*i_allUnits)

   m_admin_owner_name.c_str());

 // Become admin owner using above created name
-  bool rc = initAdminOwner();
+  bool rc = initImmOmAndSetAdminOwnerName();
 if (rc == false ) {
   LOG_NO("%s: initAdminOwner() Fail", __FUNCTION__);
   m_creation_fail = true;
@@ -2978,7 +2978,7 @@ done:
   //   Use becomeAdminOwnerOf(object) and

releaseAdminOwnerOf(object)

   //
   //
-bool SmfAdminOperation::initAdminOwner() {
+bool SmfAdminOperation::initImmOmAndSetAdminOwnerName() {
 SaAisErrorT ais_rc = SA_AIS_ERR_TRY_AGAIN;
 int timeout_try_cnt = 6;
 bool rc = true;
@@ -3020,7 +3020,7 @@ bool SmfAdminOperation::initAdminOwner() {
   // Note: m_omHandle must have been initialized
   // Note: Become admin owner of AMF cluster object
   //
-bool SmfAdminOperation::initNodeGroupOm() {
+bool SmfAdminOperation::becomeNgAdmOwnerAndInitCcb() {
 SaAisErrorT ais_rc = SA_AIS_ERR_TRY_AGAIN;
 int timeout_try_cnt = 6;
 bool rc = true;
@@ -3067,7 +3067,7 @@ bool SmfAdminOperation::initNodeGroupOm() {
   // Note: m_omHandle must have been initialized
   // Note: Release admin owner of AMF cluster object
   //
-void SmfAdminOperation::releaseNodeGroupOm() {
+void SmfAdminOperation::releaseNgAdmOwnerAndCcb() {
 TRACE_ENTER();
 SaAisErrorT ais_rc = immutil_saImmOmCcbFinalize(m_ccbHandle);
 if (ais_rc != SA_AIS_OK) {
@@ -3588,16 +3588,6 @@ bool

SmfAdminOperation::createNodeGroup(SaAmfAdminStateT i_fromState) {

 const SaImmAttrValuesT_2 *attrValues[] = {
 , , ,

NULL};

-  // 
-  // Initialize node group ccb handling
-  // Note: We become admin owner of the node group parent that must

be released

-  //   when node group operations are done.
-  bool method_rc = true;
-  if (initNodeGroupOm() == false) {
-LOG_NO("%s: initNodeGroupOm() Fail", __FUNCTION__);
-method_rc = false;
-  }
-
 // 
 // Create the node group
 // Retry if:
@@ -3607,7 +3597,16 @@ bool

SmfAdminOperation::createNodeGroup(SaAmfAdminStateT i_fromState) {

 //   Re-initialize and try again
 const uint32_t MAX_NO_RETRIES = 4;
 uint32_t retry_cnt = 0;
+  bool method_rc = true;
+  m_errno = SA_AIS_OK;
 while ((++retry_cnt <= MAX_NO_RETRIES) && (method_rc == true)) {
+// Note: OM handle and admin owner name is created in the

constructor

+if (becomeNgAdmOwnerAndInitCcb() == false) {
+  LOG_NO("%s: becomeNgAdmOwnerAndInitCcb() Fail",

__FUNCTION__);

+  method_rc = false;
+  break;
+}
+
   // Fill in nodeGroupParentDn parameter for object create operation
   SaImmClassNameT className =

const_cast("SaAmfNodeGroup");

   SaNameT nodeGroupParentDn;
@@ -3628,6 +3627,10 @@ bool

SmfAdminOperation::createNodeGroup(SaAmfAdminStateT i_fromState) {

saf_error(m_errno));
 TRACE("%s: A node group unexpectedly already exist, "
 "deleteNodeGroup", __FUNCTION__);
+
+  // Must be released so that deleteNodeGroup() can be come owner

and

+  // create a CCB for deleting
+  releaseNgAdmOwnerAndCcb();

Re: [devel] [PATCH 2/2] smf: Upgrade nodes without using node group [#2592]

[Rafael Odzakow]

One minor comment inline under [rafael] tag. I had a comment previously 
for the nodeGroupAdminOperation function which is not addressed.


[rafael] method_rc seems not to be set (to false) if the 
AdminOperationInvoke fails without reaching timeout.



A general comment to big functions with break and continue is that the 
flow is too complex to have a overview of. Consider refactoring in the 
future.




On 10/19/2017 02:16 PM, Lennart Lund wrote:

Udates after review. This commit will be merged with the fix before push
---
  src/smf/smfd/SmfUpgradeStep.cc | 90 +++---
  src/smf/smfd/SmfUpgradeStep.h  |  6 +--
  2 files changed, 43 insertions(+), 53 deletions(-)

diff --git a/src/smf/smfd/SmfUpgradeStep.cc b/src/smf/smfd/SmfUpgradeStep.cc
index 892c32602..25f816485 100644
--- a/src/smf/smfd/SmfUpgradeStep.cc
+++ b/src/smf/smfd/SmfUpgradeStep.cc
@@ -2794,7 +2794,7 @@ 
SmfAdminOperation::SmfAdminOperation(std::list *i_allUnits)
  m_admin_owner_name.c_str());
  
// Become admin owner using above created name

-  bool rc = initAdminOwner();
+  bool rc = initImmOmAndSetAdminOwnerName();
if (rc == false ) {
  LOG_NO("%s: initAdminOwner() Fail", __FUNCTION__);
  m_creation_fail = true;
@@ -2978,7 +2978,7 @@ done:
  //   Use becomeAdminOwnerOf(object) and releaseAdminOwnerOf(object)
  //
  //
-bool SmfAdminOperation::initAdminOwner() {
+bool SmfAdminOperation::initImmOmAndSetAdminOwnerName() {
SaAisErrorT ais_rc = SA_AIS_ERR_TRY_AGAIN;
int timeout_try_cnt = 6;
bool rc = true;
@@ -3020,7 +3020,7 @@ bool SmfAdminOperation::initAdminOwner() {
  // Note: m_omHandle must have been initialized
  // Note: Become admin owner of AMF cluster object
  //
-bool SmfAdminOperation::initNodeGroupOm() {
+bool SmfAdminOperation::becomeNgAdmOwnerAndInitCcb() {
SaAisErrorT ais_rc = SA_AIS_ERR_TRY_AGAIN;
int timeout_try_cnt = 6;
bool rc = true;
@@ -3067,7 +3067,7 @@ bool SmfAdminOperation::initNodeGroupOm() {
  // Note: m_omHandle must have been initialized
  // Note: Release admin owner of AMF cluster object
  //
-void SmfAdminOperation::releaseNodeGroupOm() {
+void SmfAdminOperation::releaseNgAdmOwnerAndCcb() {
TRACE_ENTER();
SaAisErrorT ais_rc = immutil_saImmOmCcbFinalize(m_ccbHandle);
if (ais_rc != SA_AIS_OK) {
@@ -3588,16 +3588,6 @@ bool SmfAdminOperation::createNodeGroup(SaAmfAdminStateT 
i_fromState) {
const SaImmAttrValuesT_2 *attrValues[] = {
, , , NULL};
  
-  // 

-  // Initialize node group ccb handling
-  // Note: We become admin owner of the node group parent that must be released
-  //   when node group operations are done.
-  bool method_rc = true;
-  if (initNodeGroupOm() == false) {
-LOG_NO("%s: initNodeGroupOm() Fail", __FUNCTION__);
-method_rc = false;
-  }
-
// 
// Create the node group
// Retry if:
@@ -3607,7 +3597,16 @@ bool SmfAdminOperation::createNodeGroup(SaAmfAdminStateT 
i_fromState) {
//   Re-initialize and try again
const uint32_t MAX_NO_RETRIES = 4;
uint32_t retry_cnt = 0;
+  bool method_rc = true;
+  m_errno = SA_AIS_OK;
while ((++retry_cnt <= MAX_NO_RETRIES) && (method_rc == true)) {
+// Note: OM handle and admin owner name is created in the constructor
+if (becomeNgAdmOwnerAndInitCcb() == false) {
+  LOG_NO("%s: becomeNgAdmOwnerAndInitCcb() Fail", __FUNCTION__);
+  method_rc = false;
+  break;
+}
+
  // Fill in nodeGroupParentDn parameter for object create operation
  SaImmClassNameT className = const_cast("SaAmfNodeGroup");
  SaNameT nodeGroupParentDn;
@@ -3628,6 +3627,10 @@ bool SmfAdminOperation::createNodeGroup(SaAmfAdminStateT 
i_fromState) {
   saf_error(m_errno));
TRACE("%s: A node group unexpectedly already exist, "
"deleteNodeGroup", __FUNCTION__);
+
+  // Must be released so that deleteNodeGroup() can be come owner and
+  // create a CCB for deleting
+  releaseNgAdmOwnerAndCcb();
bool delete_rc = deleteNodeGroup();
if (delete_rc == false) {
  LOG_NO("%s: deleteNodeGroup() Fail", __FUNCTION__);
@@ -3640,20 +3643,15 @@ bool 
SmfAdminOperation::createNodeGroup(SaAmfAdminStateT i_fromState) {
// Reinitialize and try again
LOG_NO("%s: saImmOmCcbObjectCreate_2 Fail %s", __FUNCTION__,
   saf_error(m_errno));
-  finalizeNodeGroupOm();
  
-  // After finalize a new OM handle has to be created and node group ccb

-  // handling has to be initialized
-  if (initAdminOwner() == false) {
+  // Note: After finalize a new OM handle and admin owner name has to be
+  // created
+  finalizeNodeGroupOm();
+  if (initImmOmAndSetAdminOwnerName() == false) {
  LOG_NO("%s: initAdminOwner() Fail", __FUNCTION__);
  method_rc = false;
  break;
}
-  if (initNodeGroupOm() == false) {
-

Re: [devel] [PATCH 1/1] smf: coredump and syslog flood after immnd crash [#2441]

[Rafael Odzakow]

ACK


On 10/19/2017 02:45 PM, Rafael Odzakow wrote:


One comment under [rafael] tag, everything else looks good.


On 10/18/2017 03:40 PM, Lennart Lund wrote:
When reinitializing the OI handle, done in a separate thread, then 
keep the
new handle in a local variable until the whole OI including OI set is 
done
When finished the new handle can be published in the global cb 
structure.

Also protect global variable change with imm lock mutex
---
  src/smf/smfd/smfd_campaign_oi.cc | 46 


  1 file changed, 32 insertions(+), 14 deletions(-)

diff --git a/src/smf/smfd/smfd_campaign_oi.cc 
b/src/smf/smfd/smfd_campaign_oi.cc

index 0ea3a34cc..72865a821 100644
--- a/src/smf/smfd/smfd_campaign_oi.cc
+++ b/src/smf/smfd/smfd_campaign_oi.cc
@@ -28,6 +28,7 @@
  #include 
  #include 
  #include "base/osaf_time.h"
+#include "base/saf_error.h"
    #include "osaf/configmake.h"
  #include "base/logtrace.h"
@@ -800,6 +801,7 @@ uint32_t create_campaign_objects(smfd_cb_t *cb) {
   */
  uint32_t updateImmAttr(const char *dn, SaImmAttrNameT attributeName,
 SaImmValueTypeT attrValueType, void *value) {
+  TRACE_ENTER();
    smfd_imm_lock();
    SaAisErrorT rc = immutil_update_one_rattr(
    smfd_cb->campaignOiHandle, dn, attributeName, attrValueType, 
value);
@@ -815,17 +817,17 @@ uint32_t updateImmAttr(const char *dn, 
SaImmAttrNameT attributeName,

 */
      LOG_WA(
-  "updateImmAttr(): immutil_update_one_rattr FAILED, rc = %d,"
-  "OI handle will be resurrected",
-  (int)rc);
+  "%s: immutil_update_one_rattr FAILED, '%s',"
+  "OI handle will be resurrected", __FUNCTION__, 
saf_error(rc));

  } else {
    LOG_ER(
-  "updateImmAttr(): immutil_update_one_rattr FAILED, rc = 
%d, going to assert",

-  (int)rc);
+  "%s: immutil_update_one_rattr FAILED, '%s', "
+  "going to assert", __FUNCTION__, saf_error(rc));
    osafassert(0);
  }
    }
  +  TRACE_LEAVE();
    return NCSCC_RC_SUCCESS;
  }
  @@ -1126,7 +1128,8 @@ uint32_t 
read_config_and_set_control_block(smfd_cb_t *cb) {

  if (getenv("SMF_IMM_PERSIST_CMD") == NULL) {
    // Not found in smfd.conf. Set hardcoded value for backward 
compability

    LOG_NO(
-  "Attr SMF_IMM_PERSIST_CMD is not available in SMF config 
object or smfd.conf file. Use default cmd: immdump 
/etc/opensaf/imm.xml");
+  "Attr SMF_IMM_PERSIST_CMD is not available in SMF config 
object or "
+  "smfd.conf file. Use default cmd: immdump 
/etc/opensaf/imm.xml");

    smfImmPersistCmd = "immdump " PKGSYSCONFDIR "/imm.xml";
  } else {
    smfImmPersistCmd = getenv("SMF_IMM_PERSIST_CMD");
@@ -1243,29 +1246,38 @@ void *smfd_coi_reinit_thread(void *_cb) {
    TRACE_ENTER();
    smfd_cb_t *cb = (smfd_cb_t *)_cb;
  -  SaAisErrorT rc = immutil_saImmOiInitialize_2(>campaignOiHandle,
+  SaImmOiHandleT local_imm_oi_handle = 0;
+  SaSelectionObjectT local_campaignSelectionObject = 0;
+
+  // Do not publish the OI handle in the cb-structure before the whole
+  // init sequence is done. This is in order to avoid BAD OPERATION 
return code
+  // when handling RT objects in other threads. This may happen if 
the handle is

+  // valid (recovered) but before Implementer set is done
+  //
+
+  SaAisErrorT rc = immutil_saImmOiInitialize_2(_imm_oi_handle,
 , 
);

    if (rc != SA_AIS_OK) {
  LOG_ER("saImmOiInitialize_2 failed %u", rc);
  exit(EXIT_FAILURE);
    }
  -  rc = immutil_saImmOiSelectionObjectGet(cb->campaignOiHandle,
- >campaignSelectionObject);
+  rc = immutil_saImmOiSelectionObjectGet(local_imm_oi_handle,
+ _campaignSelectionObject);
    if (rc != SA_AIS_OK) {
  LOG_ER("immutil_saImmOiSelectionObjectGet failed %u", rc);
  exit(EXIT_FAILURE);
    }
      if (cb->ha_state == SA_AMF_HA_ACTIVE) {
-    rc = immutil_saImmOiImplementerSet(cb->campaignOiHandle, 
implementerName);
+    rc = immutil_saImmOiImplementerSet(local_imm_oi_handle, 
implementerName);

  if (rc != SA_AIS_OK) {
    LOG_ER("immutil_saImmOiImplementerSet failed rc=%u 
implementer name =%s",

   rc, (char *)implementerName);
    exit(EXIT_FAILURE);
  }
  -    rc = immutil_saImmOiClassImplementerSet(cb->campaignOiHandle,
+    rc = immutil_saImmOiClassImplementerSet(local_imm_oi_handle,
campaignClassName);
  if (rc != SA_AIS_OK) {
    LOG_ER(
@@ -1274,7 +1286,7 @@ void *smfd_coi_reinit_thread(void *_cb) {
    exit(EXIT_FAILURE);
  }
  -    rc = immutil_saImmOiClassImplementerSet(cb->campaignOiHandle,
+    rc = immutil_saImmOiClassImplementerSet(local_imm_oi_handle,
smfConfi

Re: [devel] [PATCH 1/1] smf: coredump and syslog flood after immnd crash [#2441]

[Rafael Odzakow]

One comment under [rafael] tag, everything else looks good.


On 10/18/2017 03:40 PM, Lennart Lund wrote:

When reinitializing the OI handle, done in a separate thread, then keep the
new handle in a local variable until the whole OI including OI set is done
When finished the new handle can be published in the global cb structure.
Also protect global variable change with imm lock mutex
---
  src/smf/smfd/smfd_campaign_oi.cc | 46 
  1 file changed, 32 insertions(+), 14 deletions(-)

diff --git a/src/smf/smfd/smfd_campaign_oi.cc b/src/smf/smfd/smfd_campaign_oi.cc
index 0ea3a34cc..72865a821 100644
--- a/src/smf/smfd/smfd_campaign_oi.cc
+++ b/src/smf/smfd/smfd_campaign_oi.cc
@@ -28,6 +28,7 @@
  #include 
  #include 
  #include "base/osaf_time.h"
+#include "base/saf_error.h"
  
  #include "osaf/configmake.h"

  #include "base/logtrace.h"
@@ -800,6 +801,7 @@ uint32_t create_campaign_objects(smfd_cb_t *cb) {
   */
  uint32_t updateImmAttr(const char *dn, SaImmAttrNameT attributeName,
 SaImmValueTypeT attrValueType, void *value) {
+  TRACE_ENTER();
smfd_imm_lock();
SaAisErrorT rc = immutil_update_one_rattr(
smfd_cb->campaignOiHandle, dn, attributeName, attrValueType, value);
@@ -815,17 +817,17 @@ uint32_t updateImmAttr(const char *dn, SaImmAttrNameT 
attributeName,
 */
  
LOG_WA(

-  "updateImmAttr(): immutil_update_one_rattr FAILED, rc = %d,"
-  "OI handle will be resurrected",
-  (int)rc);
+  "%s: immutil_update_one_rattr FAILED, '%s',"
+  "OI handle will be resurrected", __FUNCTION__, saf_error(rc));
  } else {
LOG_ER(
-  "updateImmAttr(): immutil_update_one_rattr FAILED, rc = %d, going to 
assert",
-  (int)rc);
+  "%s: immutil_update_one_rattr FAILED, '%s', "
+  "going to assert", __FUNCTION__, saf_error(rc));
osafassert(0);
  }
}
  
+  TRACE_LEAVE();

return NCSCC_RC_SUCCESS;
  }
  
@@ -1126,7 +1128,8 @@ uint32_t read_config_and_set_control_block(smfd_cb_t *cb) {

  if (getenv("SMF_IMM_PERSIST_CMD") == NULL) {
// Not found in smfd.conf. Set hardcoded value for backward compability
LOG_NO(
-  "Attr SMF_IMM_PERSIST_CMD is not available in SMF config object or 
smfd.conf file. Use default cmd: immdump /etc/opensaf/imm.xml");
+  "Attr SMF_IMM_PERSIST_CMD is not available in SMF config object or "
+  "smfd.conf file. Use default cmd: immdump /etc/opensaf/imm.xml");
smfImmPersistCmd = "immdump " PKGSYSCONFDIR "/imm.xml";
  } else {
smfImmPersistCmd = getenv("SMF_IMM_PERSIST_CMD");
@@ -1243,29 +1246,38 @@ void *smfd_coi_reinit_thread(void *_cb) {
TRACE_ENTER();
smfd_cb_t *cb = (smfd_cb_t *)_cb;
  
-  SaAisErrorT rc = immutil_saImmOiInitialize_2(>campaignOiHandle,

+  SaImmOiHandleT local_imm_oi_handle = 0;
+  SaSelectionObjectT local_campaignSelectionObject = 0;
+
+  // Do not publish the OI handle in the cb-structure before the whole
+  // init sequence is done. This is in order to avoid BAD OPERATION return code
+  // when handling RT objects in other threads. This may happen if the handle 
is
+  // valid (recovered) but before Implementer set is done
+  //
+
+  SaAisErrorT rc = immutil_saImmOiInitialize_2(_imm_oi_handle,
 , );
if (rc != SA_AIS_OK) {
  LOG_ER("saImmOiInitialize_2 failed %u", rc);
  exit(EXIT_FAILURE);
}
  
-  rc = immutil_saImmOiSelectionObjectGet(cb->campaignOiHandle,

- >campaignSelectionObject);
+  rc = immutil_saImmOiSelectionObjectGet(local_imm_oi_handle,
+ _campaignSelectionObject);
if (rc != SA_AIS_OK) {
  LOG_ER("immutil_saImmOiSelectionObjectGet failed %u", rc);
  exit(EXIT_FAILURE);
}
  
if (cb->ha_state == SA_AMF_HA_ACTIVE) {

-rc = immutil_saImmOiImplementerSet(cb->campaignOiHandle, implementerName);
+rc = immutil_saImmOiImplementerSet(local_imm_oi_handle, implementerName);
  if (rc != SA_AIS_OK) {
LOG_ER("immutil_saImmOiImplementerSet failed rc=%u implementer name 
=%s",
   rc, (char *)implementerName);
exit(EXIT_FAILURE);
  }
  
-rc = immutil_saImmOiClassImplementerSet(cb->campaignOiHandle,

+rc = immutil_saImmOiClassImplementerSet(local_imm_oi_handle,
  campaignClassName);
  if (rc != SA_AIS_OK) {
LOG_ER(
@@ -1274,7 +1286,7 @@ void *smfd_coi_reinit_thread(void *_cb) {
exit(EXIT_FAILURE);
  }
  
-rc = immutil_saImmOiClassImplementerSet(cb->campaignOiHandle,

+rc = immutil_saImmOiClassImplementerSet(local_imm_oi_handle,
  smfConfigClassName);
  if (rc != SA_AIS_OK) {
LOG_ER(
@@ -1283,7 +1295,7 @@ void *smfd_coi_reinit_thread(void *_cb) {
exit(EXIT_FAILURE);
  }
  

[devel] [PATCH 0/1] Review Request for smf: refactor smfd folders [#2633]

[Rafael Odzakow]

Summary: smf: refactor smfd folders [#2633]
Review request for Ticket(s): 2633
Peer Reviewer(s): lennart
Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
Affected branch(es): develop
Development branch: ticket-2633
Base revision: e7fb995f41a4bfabe3d1e48bda3ba004e2935074
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 servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


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

revision 410025e485a7f6c98e51ddc504eaf1ad782c5bd8
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Tue, 17 Oct 2017 14:14:38 +0200

smf: refactor smfd folders [#2633]

 Will not compile, just a suggestion.



Added Files:

 src/smf/smfd/campaign/SmfCallback.cc
 src/smf/smfd/campaign/SmfCallback.h
 src/smf/smfd/campaign/SmfCampaign.cc
 src/smf/smfd/campaign/SmfCampaign.h
 src/smf/smfd/campaign/SmfCampaignInit.cc
 src/smf/smfd/campaign/SmfCampaignInit.h
 src/smf/smfd/campaign/SmfCampaignThread.cc
 src/smf/smfd/campaign/SmfCampaignThread.h
 src/smf/smfd/campaign/SmfCampaignWrapup.cc
 src/smf/smfd/campaign/SmfCampaignWrapup.h
 src/smf/smfd/campaign/SmfCampaignXmlParser.cc
 src/smf/smfd/campaign/SmfCampaignXmlParser.h
 src/smf/smfd/campaign/SmfCampState.cc
 src/smf/smfd/campaign/SmfCampState.h
 src/smf/smfd/campaign/SmfRollback.cc
 src/smf/smfd/campaign/SmfRollback.h
 src/smf/smfd/campaign/SmfTargetTemplate.cc
 src/smf/smfd/campaign/SmfTargetTemplate.h
 src/smf/smfd/campaign/SmfUpgradeAction.cc
 src/smf/smfd/campaign/SmfUpgradeAction.h
 src/smf/smfd/campaign/SmfUpgradeCampaign.cc
 src/smf/smfd/campaign/SmfUpgradeCampaign.h
 src/smf/smfd/campaign/SmfUpgradeMethod.cc
 src/smf/smfd/campaign/SmfUpgradeMethod.h
 src/smf/smfd/imm/smfd_campaign_oi.cc
 src/smf/smfd/imm/SmfExecControlHdl.cc
 src/smf/smfd/imm/SmfExecControlHdl.h
 src/smf/smfd/imm/SmfImmApplierHdl.cc
 src/smf/smfd/imm/SmfImmApplierHdl.h
 src/smf/smfd/imm/SmfImmOperation.cc
 src/smf/smfd/imm/SmfImmOperation.h
 src/smf/smfd/imm/SmfLongDnApplier.cc
 src/smf/smfd/imm/SmfLongDnApplier.h
 src/smf/smfd/procedure/SmfProcedureThread.cc
 src/smf/smfd/procedure/SmfProcedureThread.h
 src/smf/smfd/procedure/SmfProcState.cc
 src/smf/smfd/procedure/SmfProcState.h
 src/smf/smfd/procedure/SmfUpgradeProcedure.cc
 src/smf/smfd/procedure/SmfUpgradeProcedure.h
 src/smf/smfd/step/SmfStepState.cc
 src/smf/smfd/step/SmfStepState.h
 src/smf/smfd/step/SmfStepTypes.cc
 src/smf/smfd/step/SmfStepTypes.h
 src/smf/smfd/step/SmfUpgradeStep.cc
 src/smf/smfd/step/SmfUpgradeStep.h


Removed Files:
--
 src/smf/smfd/SmfCallback.cc
 src/smf/smfd/SmfCallback.h
 src/smf/smfd/SmfCampaign.cc
 src/smf/smfd/SmfCampaign.h
 src/smf/smfd/SmfCampaignInit.cc
 src/smf/smfd/SmfCampaignInit.h
 src/smf/smfd/SmfCampaignThread.cc
 src/smf/smfd/SmfCampaignThread.h
 src/smf/smfd/SmfCampaignWrapup.cc
 src/smf/smfd/SmfCampaignWrapup.h
 src/smf/smfd/SmfCampaignXmlParser.cc
 src/smf/smfd/SmfCampaignXmlParser.h
 src/smf/smfd/SmfCampState.cc
 src/smf/smfd/SmfCampState.h
 src/smf/smfd/smfd_campaign_oi.cc
 src/smf/smfd/SmfExecControlHdl.cc
 src/smf/smfd/SmfExecControlHdl.h
 src/smf/smfd/SmfImmApplierHdl.cc
 src/smf/smfd/SmfImmApplierHdl.h
 src/smf/smfd/SmfImmOperation.cc
 src/smf/smfd/SmfImmOperation.h
 src/smf/smfd/SmfLongDnApplier.cc
 src/smf/smfd/SmfLongDnApplier.h
 src/smf/smfd/SmfProcedureThread.cc
 src/smf/smfd/SmfProcedureThread.h
 src/smf/smfd/SmfProcState.cc
 src/smf/smfd/SmfProcState.h
 src/smf/smfd/SmfRollback.cc
 src/smf/smfd/SmfRollback.h
 src/smf/smfd/SmfStepState.cc
 src/smf/smfd/SmfStepState.h
 src/smf/smfd/SmfStepTypes.cc
 src/smf/smfd/SmfStepTypes.h
 src/smf/smfd/SmfTargetTemplate.cc
 src/smf/smfd/SmfTargetTemplate.h
 src/smf/smfd/SmfUpgradeAction.cc
 src/smf/smfd/SmfUpgradeAction.h
 src/smf/smfd/SmfUpgradeCampaign.cc
 src/smf/smfd/SmfUpgradeCampaign.h
 src/smf/smfd/SmfUpgradeMethod.cc
 src/smf/smfd/SmfUpgradeMethod.h
 src/smf/smfd/SmfUpgradeProcedure.cc
 src/smf/smfd/SmfUpgradeProcedure.h
 src/smf/smfd/SmfUpgradeStep.cc
 src/smf/smfd/SmfUpgradeStep.h


Complete diffstat:
--
 src/smf/smfd/SmfCallback.cc   |  349 --
 src/smf/smfd/SmfCallback.h|  107 -
 src/smf/smfd/SmfCampState.cc  | 2321 
 src/smf/smfd/SmfCampState.h   |  455 ---
 src/smf/smfd/SmfCampaign.cc   | 1034 --
 src/smf/smfd/SmfCampaign.h|  149 -
 src/smf/smfd/SmfCampaignInit.cc   |  310 --
 src/smf/smfd/SmfCampaignInit.h|  154 -
 src/smf/smfd/SmfC

Re: [devel] [PATCH 1/1] smf: smf: Upgrade nodes without using node group [#2592]

[Rafael Odzakow]

Comments inline

Complex patch, consider separating logical changes and refactoring into 
two patches to make it easier.



On 09/28/2017 02:58 PM, Lennart Lund wrote:

Do not create a node group for lock operations on nodes if only one node
(deactivation/activation units). This is needed to make it possible to
upgrade old OpenSAF versions. On old versions AMF will crash and cause
cyclic node reboot
---
  src/smf/smfd/SmfUpgradeStep.cc | 517 ++---
  src/smf/smfd/SmfUpgradeStep.h  |  11 +-
  src/smf/smfd/SmfUtils.cc   |   8 +
  3 files changed, 345 insertions(+), 191 deletions(-)

diff --git a/src/smf/smfd/SmfUpgradeStep.cc b/src/smf/smfd/SmfUpgradeStep.cc
index d40fac4fc..892c32602 100644
--- a/src/smf/smfd/SmfUpgradeStep.cc
+++ b/src/smf/smfd/SmfUpgradeStep.cc
@@ -2793,23 +2793,11 @@ 
SmfAdminOperation::SmfAdminOperation(std::list *i_allUnits)
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
-  // The public methods shall return fail if m_creation_fail is true
-
-  bool rc = initNodeGroupOm();
-  if (rc == false) {
-LOG_NO("%s: initNodeGroupOm Fail", __FUNCTION__);
-m_creation_fail = true;
-return;
-  }
-
-  rc = becomeAdminOwnerOfAmfClusterObj();
-  if (rc == false) {
-LOG_NO("%s: becomeAdminOwnerOfAmfClusterObj Fail", __FUNCTION__);
+  // Become admin owner using above created name
+  bool rc = initAdminOwner();
+  if (rc == false ) {
+LOG_NO("%s: initAdminOwner() Fail", __FUNCTION__);
  m_creation_fail = true;
-return;
}
  }
  
@@ -2840,16 +2828,9 @@ bool SmfAdminOperation::lock() {
  
createNodeAndSULockLists(SA_AMF_ADMIN_UNLOCKED);
  
-  rc = changeNodeGroupAdminState(SA_AMF_ADMIN_UNLOCKED, SA_AMF_ADMIN_LOCK);

-  if (rc == false) {
-LOG_NO("%s: changeNodeGroupAdminState() Fail %s", __FUNCTION__,
-   saf_error(m_errno));
-goto done;
-  }
-
-  rc = adminOperationSerialized(SA_AMF_ADMIN_LOCK, m_suList);
+  rc = changeAdminState(SA_AMF_ADMIN_UNLOCKED, SA_AMF_ADMIN_LOCK);
if (rc == false) {
-LOG_NO("%s: setAdminStateSUs() Fail %s", __FUNCTION__, saf_error(m_errno));
+LOG_NO("%s setAdminState() Fail", __FUNCTION__);
}
  
  done:

@@ -2880,17 +2861,9 @@ bool SmfAdminOperation::lock_in() {
  
createNodeAndSULockLists(SA_AMF_ADMIN_LOCKED);
  
-  rc = changeNodeGroupAdminState(SA_AMF_ADMIN_LOCKED,

- SA_AMF_ADMIN_LOCK_INSTANTIATION);
+  rc = changeAdminState(SA_AMF_ADMIN_LOCKED, SA_AMF_ADMIN_LOCK_INSTANTIATION);
if (rc == false) {
-LOG_NO("%s: changeNodeGroupAdminState() Fail %s", __FUNCTION__,
-   saf_error(m_errno));
-goto done;
-  }
-
-  rc = adminOperationSerialized(SA_AMF_ADMIN_LOCK_INSTANTIATION, m_suList);
-  if (rc == false) {
-LOG_NO("%s: setAdminStateSUs() Fail %s", __FUNCTION__, saf_error(m_errno));
+LOG_NO("%s setAdminState() Fail", __FUNCTION__);
}
  
  done:

@@ -2924,17 +2897,10 @@ bool SmfAdminOperation::unlock_in() {
// Note: This actually change state to SA_AMF_ADMIN_LOCKED
//   The admin operation is SA_AMF_ADMIN_UNLOCK_INSTANTIATION but
//   there is no SA_AMF_ADMIN_UNLOCK_INSTANTIATION state
-  rc = changeNodeGroupAdminState(SA_AMF_ADMIN_LOCKED_INSTANTIATION,
- SA_AMF_ADMIN_UNLOCK_INSTANTIATION);
+  rc = changeAdminState(SA_AMF_ADMIN_LOCKED_INSTANTIATION,
+ SA_AMF_ADMIN_UNLOCK_INSTANTIATION);
if (rc == false) {
-LOG_NO("%s: changeNodeGroupAdminState() Fail %s", __FUNCTION__,
-   saf_error(m_errno));
-goto done;
-  }
-
-  rc = adminOperationSerialized(SA_AMF_ADMIN_UNLOCK_INSTANTIATION, m_suList);
-  if (rc == false) {
-LOG_NO("%s: setAdminStateSUs() Fail %s", __FUNCTION__, saf_error(m_errno));
+LOG_NO("%s setAdminState() Fail", __FUNCTION__);
}
  
  done:

@@ -2965,16 +2931,9 @@ bool SmfAdminOperation::unlock() {
  
createNodeAndSUUnlockLists(SA_AMF_ADMIN_LOCKED);
  
-  rc = changeNodeGroupAdminState(SA_AMF_ADMIN_LOCKED, SA_AMF_ADMIN_UNLOCK);

-  if (rc == false) {
-LOG_NO("%s: changeNodeGroupAdminState() Fail %s", __FUNCTION__,
-   saf_error(m_errno));
-goto done;
-  }
-
-  rc = adminOperationSerialized(SA_AMF_ADMIN_UNLOCK, m_suList);
+  rc = changeAdminState(SA_AMF_ADMIN_LOCKED, SA_AMF_ADMIN_UNLOCK);
if (rc == false) {
-LOG_NO("%s: setAdminStateSUs() Fail %s", __FUNCTION__, saf_error(m_errno));
+LOG_NO("%s changeAdminState() Fail", __FUNCTION__);
}
  
  done:

@@ -3013,15 +2972,17 @@ done:
  /// SmfSetAdminState Private
  /// ---
  
-/// Get all needed IMM handles. Updates corresponding member variables

-/// Return false if fail
-///
-bool SmfAdminOperation::initNodeGroupOm() {
+// Initialize an OM (get an OM handle) and become admin owner with
+// admin 

[devel] [PATCH 1/1] base: double start failed [#2622]

[Rafael Odzakow]

Moving the setup_env caused ubuntu 14.04 systems to fail as they dont
have the /var/lock/subsys directory by default.
---
 src/nid/opensafd.in | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in
index d7035f5..ed7818f 100644
--- a/src/nid/opensafd.in
+++ b/src/nid/opensafd.in
@@ -97,8 +97,6 @@ setup_env() {
getent passwd $OPENSAF_USER > /dev/null && chown 
$OPENSAF_USER $directory
fi
done
-   rm -f $pkgpiddir/*
-   rm -f $pkglogdir/nid.log
 }
 
 clean_shm() {
@@ -235,6 +233,8 @@ mutex_remove() {
 }
 
 start() {
+   setup_env
+
if ! mutex_create; then
return 1
fi
@@ -249,11 +249,11 @@ start() {
return $RETVAL
fi
 
+   rm -f $pkgpiddir/*
+   rm -f $pkglogdir/nid.log
 
[ -x $daemon ] || exit 5
 
-   setup_env
-
check_transport
 
logger -t $osafprog "Starting OpenSAF Services($osafversion - 
$osafcshash) (Using $MDS_TRANSPORT)"
-- 
2.7.4


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

[devel] [PATCH 0/1] Review Request for base: double start failed [#2622]

[Rafael Odzakow]

Summary: base: double start failed [#2622]
Review request for Ticket(s): 2622
Peer Reviewer(s): hans / zoran
Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
Affected branch(es): develop
Development branch: ticket-2622
Base revision: 393adcde9a590ab05d78de265b1778d359d9d732
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 y
 SAF servicesn
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


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

revision 0b6e3596c1794bdb0c996b6ac46c6d68521b1bcd
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Mon, 16 Oct 2017 13:40:19 +0200

base: double start failed [#2622]

Moving the setup_env caused ubuntu 14.04 systems to fail as they dont
have the /var/lock/subsys directory by default.



Complete diffstat:
--
 src/nid/opensafd.in | 8 
 1 file changed, 4 insertions(+), 4 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 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 smf: Upgrade failed due to CCB aborted by imm sync request [#2584]

[Rafael Odzakow]

ACK


On 10/11/2017 08:08 AM, Vijay Roy wrote:

Summary: smf: Upgrade failed due to CCB aborted by imm sync request [#2584]
Review request for Ticket(s): 2584
Peer Reviewer(s): lennart.l...@ericsson.com,rafael.odza...@ericsson.com
Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
Affected branch(es): develop
Development branch: ticket-2584
Base revision: 39b6568271fb6291cd654c8edf5b9104968bf3c4
Personal repository: git://git.code.sf.net/u/vijayroy/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):
-
*** EXPLAIN/COMMENT THE PATCH SERIES HERE ***

revision 968aa78226d827142b344518f37782e3abe1489f
Author: Vijay Roy 
Date:   Wed, 11 Oct 2017 10:27:59 +0530

smf: Upgrade failed due to CCB aborted by imm sync request [#2584]

The Patch provides the fix where smfCreateRollbackElement return OK to avoid 
failed/ERR_EXIST situation.
Also fixed the logging of messages correctly.

* This issue is a by-product of the fix/patch provided at commit 
44d113c4fa669065afe78d70bc81c5297d79ec0e.



Complete diffstat:
--
  src/smf/smfd/SmfCampaignWrapup.cc | 67 +++
  1 file changed, 40 insertions(+), 27 deletions(-)


Testing Commands:
-
*** LIST THE COMMAND LINE TOOLS/STEPS TO TEST YOUR CHANGES ***

  1. Trigger SMF MW upgrade with more then 10 objects to get hold of IMM 
sync.
  2. Set current MW as 5.1 version
  3. Configure SC-1, SC-2, PL-3
  4. Initiate SMF MW upgrade from 5.1 to 5.2  5. During upgrade add the node 
PL-4. (To Trigger the IMM Sync as listed at point 1)



Testing, Expected Results:
--
*** PASTE COMMAND OUTPUTS / TEST RESULTS ***
  1. Upgrade Campaign Wrapup should successfully retry during IMM sync instead 
of failed.

Conditions of Submission:
-
*** HOW MANY DAYS BEFORE PUSHING, CONSENSUS ETC ***


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 

Re: [devel] [PATCH 1/1] base: double start failed [#2622]

[Rafael Odzakow]

Just tried it that was not the case for patch, still got the "*"


c0b25cd7a1a94d386d813735c72d22abded8583b

base: Atomically create pid file from temporary pid file V2 [#2432]



On 10/10/2017 02:39 PM, Zoran Milinkovic wrote:

Hi,

Reviewed and tested the patch.
Ack from me with minor comment.

When OpenSAF is started the second time, it exits with "*". It would be good to 
write some text why OpenSAF didn't succeed to start, as it was a case with Hans's patch 
earlier.

Thanks,
Zoran

-Original Message-
From: Rafael Odzakow
Sent: den 10 oktober 2017 14:08
To: Zoran Milinkovic <zoran.milinko...@ericsson.com>; Hans Nordebäck 
<hans.nordeb...@ericsson.com>
Cc: opensaf-devel@lists.sourceforge.net; Rafael Odzakow 
<rafael.odza...@ericsson.com>
Subject: [PATCH 1/1] base: double start failed [#2622]

Previously named function "check_env" overwrites pid file. Move it to after 
running pidofproc for amfnd pid.
---
  src/nid/opensafd.in | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in index effe87d..d7035f5 
100644
--- a/src/nid/opensafd.in
+++ b/src/nid/opensafd.in
@@ -235,8 +235,6 @@ mutex_remove() {
  }
  
  start() {

-   setup_env
-
if ! mutex_create; then
return 1
fi
@@ -254,6 +252,8 @@ start() {
  
  	[ -x $daemon ] || exit 5
  
+	setup_env

+
check_transport
  
  	logger -t $osafprog "Starting OpenSAF Services($osafversion - $osafcshash) (Using $MDS_TRANSPORT)"

--
2.7.4





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

[devel] [PATCH 0/1] Review Request for base: double start failed [#2622]

[Rafael Odzakow]

Summary: base: double start failed [#2622]
Review request for Ticket(s): 2622
Peer Reviewer(s): zoran/hans
Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
Affected branch(es): develop
Development branch: ticket-2622
Base revision: 30fdde2868dce841d08e697b39c1bc753346d8a4
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 y
 SAF servicesn
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


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

revision e8c8e1648cd6361692374e36f2175a2d52de
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Tue, 10 Oct 2017 14:00:36 +0200

base: double start failed [#2622]

Previously named function "check_env" overwrites pid file. Move it to
after running pidofproc for amfnd pid.



Complete diffstat:
--
 src/nid/opensafd.in | 4 ++--
 1 file changed, 2 insertions(+), 2 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 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] base: double start failed [#2622]

[Rafael Odzakow]

Previously named function "check_env" overwrites pid file. Move it to
after running pidofproc for amfnd pid.
---
 src/nid/opensafd.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in
index effe87d..d7035f5 100644
--- a/src/nid/opensafd.in
+++ b/src/nid/opensafd.in
@@ -235,8 +235,6 @@ mutex_remove() {
 }
 
 start() {
-   setup_env
-
if ! mutex_create; then
return 1
fi
@@ -254,6 +252,8 @@ start() {
 
[ -x $daemon ] || exit 5
 
+   setup_env
+
check_transport
 
logger -t $osafprog "Starting OpenSAF Services($osafversion - 
$osafcshash) (Using $MDS_TRANSPORT)"
-- 
2.7.4


--
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: try to wait for opensafd status before reboot [#2464]

[Rafael Odzakow]

On 10/04/2017 11:35 AM, Hans Nordebäck wrote:

Hi Rafael,

I have one question on this patch below. /Thanks HansN

-Original Message-
From: Lennart Lund [mailto:lennart.l...@ericsson.com]
Sent: den 25 september 2017 13:44
To: Rafael Odzakow <rafael.odza...@ericsson.com>
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] [PATCH 1/1] smf: try to wait for opensafd status before 
reboot [#2464]

Ack

Thanks
Lennart


-Original Message-
From: Rafael Odzakow
Sent: den 14 september 2017 13:34
To: Lennart Lund <lennart.l...@ericsson.com>
Cc: opensaf-devel@lists.sourceforge.net; Rafael Odzakow
<rafael.odza...@ericsson.com>
Subject: [PATCH 1/1] smf: try to wait for opensafd status before
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.

- Change smf remote command to have two versions, one that logs errors of
   the endpoint command and one without error logging.
---
  src/smf/smfd/SmfUpgradeStep.cc |  24 ++
  src/smf/smfd/smfd_smfnd.c  | 100 ++--
-
  src/smf/smfd/smfd_smfnd.h  |   8 +++-
  3 files changed, 95 insertions(+), 37 deletions(-)

diff --git a/src/smf/smfd/SmfUpgradeStep.cc
b/src/smf/smfd/SmfUpgradeStep.cc index ddd96a0..d40fac4 100644
--- a/src/smf/smfd/SmfUpgradeStep.cc
+++ b/src/smf/smfd/SmfUpgradeStep.cc
@@ -54,6 +54,7 @@
  #include "smf/smfd/SmfRollback.h"
  #include "smf/smfd/SmfUtils.h"
  #include "osaf/immutil/immutil.h"
+#include "osaf/configmake.h"
  #include "smf/smfd/smfd_smfnd.h"
  #include "smfd.h"
  #include "base/osaf_time.h"
@@ -2316,6 +2317,29 @@ bool SmfUpgradeStep::nodeReboot() {
goto done;
  }

+// Wait for a good opensafd status. If retrying fails give up and reboot
+// anyway.
+int counter = 0;
+while (counter < 5) {
+  TRACE("check status of opensafd");
+  std::string command = LSBINITDIR;
+  command += "/opensafd status";
+  cmdrc = smfnd_exec_remote_cmdnolog(command.c_str(), ,
+ cliTimeout, localTimeout);

[HansN]  is the below code correct, shouldn't it be the following?:
   if ((cmdrc  & 0x) == SMFSV_CMD_RESULT_CODE &&
   (cmdrc & 0x) == 0) {
 LOG_NO("opensafd status OK");
 break;
   } else {
  // The status is not OK, try again
   LOG_WA("opensafd status, retcode[%u] retry in 2 seconds",
  cmdrc & 0x);
   struct timespec time = {2, 0};
   osaf_nanosleep();
   counter += 1;
   }
Instead of:

+  if ((cmdrc  & 0x) == SMFSV_CMD_RESULT_CODE &&
+  (cmdrc & 0x) != 0) {
+  // The status is not OK, try again
+  LOG_WA("opensafd status, retcode[%u] retry in 2 seconds",
+ cmdrc & 0x);
+  struct timespec time = {2, 0};
+  osaf_nanosleep();
+  counter += 1;
+  } else {
+LOG_NO("opensafd status OK");
+break;
+  }
+}
+
 [Rafael] It is true that MDS errors are not handled for this call. If 
MDS issues arise this function continues to a reboot directly which is 
actually preferable. Having a MDS errors here means that something is 
already wrong with the system so there is no use to hang around for a 
good state. Improvement is to add an extra check before logging OK and 
to add which node is affected.



  /* When executing a reboot command on a node the command will
never return
 so we want a short local timeout. Since the smfnd is handling the
 cli timeout we want that to be much longer so that the reboot
command diff --git a/src/smf/smfd/smfd_smfnd.c
b/src/smf/smfd/smfd_smfnd.c index 7aadaf9..c48adb2 100644
--- a/src/smf/smfd/smfd_smfnd.c
+++ b/src/smf/smfd/smfd_smfnd.c
@@ -230,6 +230,44 @@ uint32_t smfnd_down(SaClmNodeIdT i_node_id)
return NCSCC_RC_FAILURE;
  }

+/*
+   Log errors from smfnd_main_remote_command
+ * @param i_cmd Name of remote command that was executed
+ * @param i_timeout Max time out for the remote command in 10 ms
+ * @param i_result Result code from smfnd_main_remote_cmd */ void
+log_rsp_errors(const char *i_cmd, uint32_t i_timeout, uint32_t
i_result) {
+  if (i_result != 0) { /* 0 = cmd OK */
+switch (i_result & 0x) {
+  case SMFSV_CMD_EXEC_FAILED: {
+LOG_ER("Command %s failed to start (%u)",
+   i_cmd, i_result & 0x);
+break;
+  }
+  case SMFSV

Re: [devel] [PATCH 0/1] Review Request for smf: fix to avoid core dump during smf upgrade while imm sync [#2550]

[Rafael Odzakow]

late but here is the ACK


On 08/28/2017 01:46 PM, Vijay Roy wrote:

Summary: smf: fix to avoid core dump during smf upgrade while imm sync [#2550]
Review request for Ticket(s): 2550
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
Development branch: ticket-2550
Base revision: a79bb4c527ec3c59a61ce6552184c18213fe4acd
Personal repository: git://git.code.sf.net/u/vijayroy/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):
-
*** EXPLAIN/COMMENT THE PATCH SERIES HERE ***

revision 662623d9626b14ba802ac5bdbb9f92968a29066f
Author: Vijay Roy 
Date:   Mon, 28 Aug 2017 16:49:23 +0530

smf: fix to avoid core dump during smf upgrade while imm sync [#2550]



Complete diffstat:
--
  src/smf/smfd/SmfUpgradeStep.cc | 23 ---
  1 file changed, 20 insertions(+), 3 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 threaded patch review.

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

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




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

[devel] [PATCH 0/1] Review Request for nid: order of system log print out is not correct [#2541]

[Rafael Odzakow]

Summary: nid: order of system log print out is not correct [#2541]
Review request for Ticket(s): 2541
Peer Reviewer(s): anders, hans
Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
Affected branch(es): develop
Development branch: ticket-2541
Base revision: 4aec4a89cadeff7a642ae49bbb6c638632e73b7e
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 y
 SAF servicesn
 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):
-
*** EXPLAIN/COMMENT THE PATCH SERIES HERE ***

revision afcdbe9be03790e7b80b467194d711430a916b82
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Wed, 2 Aug 2017 10:08:48 +0200

nid: order of system log print out is not correct [#2541]

Using echo -n in opensafd causes delay write to log in a systemd
environment causing unconsistent order of the logs. "Starting opensaf"
will end up after "Startup finished" in the system log.



Complete diffstat:
--
 src/nid/opensafd.in | 6 ++
 1 file changed, 2 insertions(+), 4 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 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: no node locking when procedures are empty [#2521]

[Rafael Odzakow]

---
 src/smf/smfd/SmfUpgradeProcedure.cc | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/smf/smfd/SmfUpgradeProcedure.cc 
b/src/smf/smfd/SmfUpgradeProcedure.cc
index 1b8afe806..2937c70ee 100644
--- a/src/smf/smfd/SmfUpgradeProcedure.cc
+++ b/src/smf/smfd/SmfUpgradeProcedure.cc
@@ -572,6 +572,22 @@ bool SmfUpgradeProcedure::calculateRollingSteps(
   const std::list  =
   nodeTemplate->getActivationUnitTemplateList();
 
+  // If we have all empty elements in a procedure do not create steps for it.
+  // The reason is that we do not want to lock/unlock nodes when there is no
+  // software to install or remove.
+  if (m_beforeLock.empty() &&
+  m_beforeTerm.empty() &&
+  m_afterImmModify.empty() &&
+  m_afterInstantiate.empty() &&
+  m_afterUnlock.empty() &&
+  nodeTemplate->getSwInstallList().empty() &&
+  nodeTemplate->getSwRemoveList().empty() &&
+  byTemplate->getTargetEntityTemplate().empty() &&
+  actUnitTemplates.size() == 0) {
+LOG_WA("%s: not creating step when elements are empty", __FUNCTION__);
+return true;
+  }
+
   if (actUnitTemplates.size() == 0) {
 /* No activation unit templates, use node list as activation/deactivation
  * units */
-- 
2.13.0


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

[devel] [PATCH 0/1] Review Request for smf: 20 seconds timeout in getting node destination is not enough [#2499]

[Rafael Odzakow]

Summary: smf: 20 seconds timeout in getting node destination is not enough 
[#2499]
Review request for Ticket(s): 2499
Peer Reviewer(s): lennart/reddy
Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
Affected branch(es): develop
Development branch: ticket-2499
Base revision: f089f030a322a43c79f3f259f07a4c42bb4d0da1
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 b48d48489837dafbf335e5a30bd57f0694f4654f
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Wed, 28 Jun 2017 16:08:38 +0200

smf: 20 seconds timeout in getting node destination is not enough [#2499]

SmfCliCommandAction::execute after cluster reboot did not use
smfRebootTimeout to wait for node to come back up. All commands that can
be issued after reboot should use smfRebootTimeout configuration.



Complete diffstat:
--
 src/smf/smfd/SmfUpgradeStep.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


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 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] base: Try again for opensafd stop [#2459]

[Rafael Odzakow]

Internally opensafd creates a mutex during start/stop to avoid parallel
execution. Makes mutex more robust and add a short retry if mutex is
taken.
---
 src/nid/opensafd.in | 155 +---
 1 file changed, 88 insertions(+), 67 deletions(-)

diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in
index d316967c5..57d374361 100644
--- a/src/nid/opensafd.in
+++ b/src/nid/opensafd.in
@@ -196,19 +196,56 @@ check_transport() {
fi
 }
 
+# Create a mutex for start/stop on the filesystem. Will use trap if available.
+mutex_create() {
+   timeout=10
+   interval=2
+   while [ $timeout -gt 0 ]; do
+   if mkdir "$lockfile_inprogress"; then
+   trap 'rmdir "$lockfile_inprogress"; exit $?' INT TERM 
EXIT 2> /dev/null
+   return 0
+   else
+   # lockfile exist, try again until timeout
+   if [ $timeout -eq 10 ]; then  # log only one time
+   log_warning_msg "opensafd start/stop in 
progress. Waiting for lockfile to be removed"
+   logger -t $osafprog "opensafd start/stop in 
progress. Waiting for lockfile to be removed"
+   fi
+   sleep $interval
+   timeout=$((timeout-interval))
+   fi
+   done
+
+   log_warning_msg "opensafd start/stop already in progress. Unable to 
continue"
+   logger -t $osafprog "opensafd start/stop already in progress. Unable to 
continue"
+   log_warning_msg "To forcefully start/stop OpenSAF remove 
$lockfile_inprogress"
+   logger -t $osafprog "To forcefully start/stop OpenSAF remove 
$lockfile_inprogress"
+   return 1
+}
+
+mutex_remove() {
+   rmdir "$lockfile_inprogress" 2> /dev/null
+   trap - INT TERM EXIT 2> /dev/null
+}
+
 start() {
+   if ! mutex_create; then
+   return 1
+   fi
+
export LD_LIBRARY_PATH=$pkglibdir:$LD_LIBRARY_PATH
 pidofproc -p $amfnd_pid $amfnd_bin > /dev/null 2>&1
lsb_status=$?
if [ $lsb_status -eq 0 ]; then
-   RETVAL=0
+   RETVAL=0
log_success_msg
+   mutex_remove
return $RETVAL
fi
 
 
[ -x $daemon ] || exit 5
 
+# Does more than check ...
check_env
check_transport
 
@@ -218,85 +255,69 @@ start() {
#enable_coredump
 
echo -n "Starting OpenSAF Services (Using $MDS_TRANSPORT):"
-   if [ -e "$lockfile_inprogress" ]; then
-   RETVAL=1
-   log_warning_msg "opensafd start/stop already in progress. 
Unable to continue"
-   logger -t $osafprog "opensafd start/stop already in progress. 
Unable to continue"
-   log_warning_msg "To forcefully start/stop OpenSAF remove 
$lockfile_inprogress"
-   logger -t $osafprog "To forcefully start/stop OpenSAF remove 
$lockfile_inprogress"
+   start_daemon $binary $args
+   RETVAL=$?
+   if [ $RETVAL -eq 0 ]; then
+   logger -t $osafprog "OpenSAF($osafversion - $osafcshash) 
services successfully started"
+   touch $lockfile
+   log_success_msg
else
-   touch "$lockfile_inprogress"
-   start_daemon $binary $args
-   RETVAL=$?
-   if [ $RETVAL -eq 0 ]; then
-   logger -t $osafprog "OpenSAF($osafversion - 
$osafcshash) services successfully started"
-   touch $lockfile
-   log_success_msg
+   final_clean
+   log_failure_msg
+   if [ $REBOOT_ON_FAIL_TIMEOUT -ne 0 ]; then
+   logger -t $osafprog "Starting OpenSAF failed, 
rebooting..."
+   sleep $REBOOT_ON_FAIL_TIMEOUT
+   mutex_remove
+   /sbin/reboot &
else
-   final_clean
-   log_failure_msg
-   if [ $REBOOT_ON_FAIL_TIMEOUT -ne 0 ]; then
-   logger -t $osafprog "Starting OpenSAF failed, 
rebooting..." 
-   sleep $REBOOT_ON_FAIL_TIMEOUT
-   rm -f "$lockfile_inprogress"
-   /sbin/reboot &
-   else
-   logger -t $osafprog "Starting OpenSAF failed"
-   fi
+   logger -t $osafprog "Starting OpenSAF failed"
fi
-   rm -f "$lockfile_inprogress"
fi
+   mutex_remove
return $RETVAL
 }
 
 stop() {
-   logger -t $osafprog "Stopping OpenSAF Services"
+   if ! mutex_create; then
+   return 1
+   fi
 
-   if [ -e "$lockfile_inprogress" ]; then
-   RETVAL=1
-   log_warning_msg "opensafd start/stop 

[devel] [PATCH 0/1] Review Request for base: Try again for opensafd stop [#2459]

[Rafael Odzakow]

Summary: base: Try again for opensafd stop [#2459]
Review request for Ticket(s): 2459
Peer Reviewer(s): anders/hans
Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
Affected branch(es): develop
Development branch: ticket-2459
Base revision: 664e46e54ef3c4b2e11b84e5efc73916ba6f6fc2
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 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):
-
Changed according to comments. Tested

revision 29bb1d48b59cad1fed1b76ac276afde4d77847f9
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Thu, 8 Jun 2017 12:24:35 +0200

base: Try again for opensafd stop [#2459]

Internally opensafd creates a mutex during start/stop to avoid parallel
execution. Makes mutex more robust and add a short retry if mutex is
taken.



Complete diffstat:
--
 src/nid/opensafd.in | 155 +---
 1 file changed, 88 insertions(+), 67 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 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/1] base: Try again for opensafd stop [#2459]

[Rafael Odzakow]

Thanks I am trying to implement the suggestions and will send out a new 
patch soon.



On 06/02/2017 08:51 AM, Hans Nordebäck wrote:

Hi Rafael,

I forgot one thing, not to say that you should change your patch, only 
as an example as we use inotify in opensaf,


the following may also work:

wait_for_lockfile_clear() {
  inotifywait -q -t 20 -e delete_self $lockfile_inprogress
  if [ $? = 2 ]; then
return 1
  else
touch $lockfile_inprogress
return 0
  fi
}

/Hans

On 06/02/2017 07:27 AM, Hans Nordebäck wrote:

ack, code review only.

Minor comments, in current opensafd script, the test and create of 
the lockfile is not atomic, so there is


a window for race. Perhaps we can move the creation of the lockfile 
to function "wait_for_lockfile_clear",


and make the  test and create of the lockfile atomic?

/HansN


On 06/01/2017 02:37 PM, Rafael Odzakow wrote:

Internally opensafd creates a lock file during start/stop to avoid
parallel execution. Wait for this lockfile to be released when a 
call to

opensafd stop is done.
---
  src/nid/opensafd.in | 19 +--
  1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in
index e7683bd7e..df90331a6 100644
--- a/src/nid/opensafd.in
+++ b/src/nid/opensafd.in
@@ -196,6 +196,22 @@ check_transport() {
  fi
  }
  +wait_for_lockfile_clear() {
+local timeout=10
+local interval=2
+while [ $timeout -gt 0 ]; do
+if [ -e "$lockfile_inprogress" ]; then
+log_warning_msg "opensafd start/stop in 
progress. Wait for lockfile to be removed"
+logger -t $osafprog "opensafd start/stop in 
progress. Wait for lockfile to be removed"

+sleep $interval
+else
+return 0
+fi
+timeout=`expr $timeout - $interval`
+done
+return 1
+}
+
  start() {
  export LD_LIBRARY_PATH=$pkglibdir:$LD_LIBRARY_PATH
  pidofproc -p $amfnd_pid $amfnd_bin > /dev/null 2>&1
@@ -251,8 +267,7 @@ start() {
stop() {
  logger -t $osafprog "Stopping OpenSAF Services"
-
-if [ -e "$lockfile_inprogress" ]; then
+if ! wait_for_lockfile_clear; then
  RETVAL=1
  log_warning_msg "opensafd start/stop already in progress. 
Unable to continue"
  logger -t $osafprog "opensafd start/stop already in 
progress. Unable to continue"








--
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] base: Try again for opensafd stop [#2459]

[Rafael Odzakow]

Internally opensafd creates a lock file during start/stop to avoid
parallel execution. Wait for this lockfile to be released when a call to
opensafd stop is done.
---
 src/nid/opensafd.in | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in
index e7683bd7e..df90331a6 100644
--- a/src/nid/opensafd.in
+++ b/src/nid/opensafd.in
@@ -196,6 +196,22 @@ check_transport() {
fi
 }
 
+wait_for_lockfile_clear() {
+local timeout=10
+local interval=2
+while [ $timeout -gt 0 ]; do
+if [ -e "$lockfile_inprogress" ]; then
+log_warning_msg "opensafd start/stop in progress. Wait for 
lockfile to be removed"
+logger -t $osafprog "opensafd start/stop in progress. Wait 
for lockfile to be removed"
+sleep $interval
+else
+return 0
+fi
+timeout=`expr $timeout - $interval`
+done
+return 1
+}
+
 start() {
export LD_LIBRARY_PATH=$pkglibdir:$LD_LIBRARY_PATH
 pidofproc -p $amfnd_pid $amfnd_bin > /dev/null 2>&1
@@ -251,8 +267,7 @@ start() {
 
 stop() {
logger -t $osafprog "Stopping OpenSAF Services"
-
-   if [ -e "$lockfile_inprogress" ]; then
+if ! wait_for_lockfile_clear; then
RETVAL=1
log_warning_msg "opensafd start/stop already in progress. 
Unable to continue"
logger -t $osafprog "opensafd start/stop already in progress. 
Unable to continue"
-- 
2.11.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] base: Improve state report for opensafd [#2459]

[Rafael Odzakow]

Only thing you are telling me is to ignore the implementation.


It seems you still do not fully understand the issue. I am done 
repeating myself.



On 06/01/2017 12:17 PM, Hans Nordebäck wrote:
Again, opensaf status returns either 0 "opensaf system is running" or 
3 "opensaf system is not running".
As I also commented before, what is the problem you are trying to 
solve? If SMF orders reboot and
opensaf stop fails the node will be rebooted anyway, you replied ... " 
opensafd but from services that can not handle a abrupt reboot."
Which services are you referring to? The system may be abrubtly 
rebooted at any time.


 /Hans

-----Original Message-
From: Rafael Odzakow
Sent: den 1 juni 2017 10:41
To: Hans Nordebäck <hans.nordeb...@ericsson.com>; Anders Widell 
<anders.wid...@ericsson.com>

Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1/1] base: Improve state report for opensafd [#2459]

This "definition" is flawed.


opensafd stop is issued by the system when a node receives the reboot 
command. It is not directly called by SMF.


As the issuer of the reboot command SMF needs to know if the stop is 
possible to execute because a prior start might still be ongoing.


With your suggestion Hans SMF would also find out the status of AMF 
pid and amf-status command. I do not like to drag in unnecessary 
dependencies.




On 05/31/2017 01:59 PM, Hans Nordebäck wrote:
> opensafd status reports if opensaf is running or not. There is a
> "window" from where amfnd is up and til the
>
> "lockfile_inprogress" is removed. This "window" is handled with the
> suggested change.
>
> The definition of a running opensaf is that amfnd is running and now
> also that
>
> the "lockfile_inprogress" file does not exist. If amfnd stops running
> the node will immediately be rebooted.
>
> It is not necessary to check all services.
>
> /Hans
>
>
>
> On 05/31/2017 01:35 PM, Rafael Odzakow wrote:
>> I don't agree with this suggestion having AMF in the status report of
>> opensafd init script does not fit in here. AMF is not OpenSAF it is
>> only a subset.
>>
>> - Either have all services report status, or
>>
>> - Have only the init script reports it internal status
>>
>> The patch is avoiding this issue by creating a new return code
>> because a real solution would be NBC. But as this script is pretty
>> central to OpenSAF I am thinḱing NBC route would be better.
>>
>>
>> On 05/31/2017 12:42 PM, Hans Nordebäck wrote:
>>> Hi Rafael,
>>>
>>> not tested, but perhaps we can do this check instead?:
>>>
>>> status() {
>>>
>>> amfpid=`pidofproc -p $amfnd_pid $amfnd_bin`
>>>
>>>     if [[ -n "$amfpid" && ! -f "$lockfile_inprogress" ]; then
>>> amf-state siass ha
>>> RETVAL=$?
>>> else
>>> echo "The OpenSAF HA Framework is not running"
>>> RETVAL=3
>>> fi
>>>
>>> return $RETVAL
>>> }
>>>
>>> /Hans
>>>
>>>
>>> On 05/19/2017 12:46 PM, Rafael Odzakow wrote:
>>>> Internally opensafd creates a lock file during start/stop to avoid
>>>> parallel execution. To allow others to query the state this ticket
>>>> will
>>>> use the opensafd lockfile to report the status of start/stop when
>>>> requested with "opensafd status"
>>>> ---
>>>>   src/nid/opensafd.in | 8 +++-
>>>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in
>>>> index e7683bd7e..c93cca7e1 100644
>>>> --- a/src/nid/opensafd.in
>>>> +++ b/src/nid/opensafd.in
>>>> @@ -326,8 +326,14 @@ forcereload() {
>>>>   }
>>>> status() {
>>>> +
>>>>   amfpid=`pidofproc -p $amfnd_pid $amfnd_bin`
>>>> -if [ -n "$amfpid" ]; then
>>>> +
>>>> +if [ -e "$lockfile_inprogress" ]; then
>>>> +echo "Lockfile taken, OpenSAF start/stop is in
>>>> progress"
>>>> +# LSB defines 150-199 as application reserved exit
>>>> codes
>>>> +RETVAL=150
>>>> +elif [ -n "$amfpid" ]; then
>>>>   amf-state siass ha
>>>>   RETVAL=$?
>>>>   else
>>>
>>
>>
>




--
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] base: Improve state report for opensafd [#2459]

[Rafael Odzakow]

1. Not possible, check my other response.

2. I am OK with that solution.


On 06/01/2017 10:33 AM, Anders Widell wrote:

Hi!

Can't you return 150 from the opensafd stop command instead? Then the 
caller will know that he has to retry opensafd stop. Or maybe put the 
retry inside the opensafd script?


/ Anders W


On 05/19/2017 12:46 PM, Rafael Odzakow wrote:

Internally opensafd creates a lock file during start/stop to avoid
parallel execution. To allow others to query the state this ticket will
use the opensafd lockfile to report the status of start/stop when
requested with "opensafd status"
---
  src/nid/opensafd.in | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in
index e7683bd7e..c93cca7e1 100644
--- a/src/nid/opensafd.in
+++ b/src/nid/opensafd.in
@@ -326,8 +326,14 @@ forcereload() {
  }
status() {
+
  amfpid=`pidofproc -p $amfnd_pid $amfnd_bin`
-if [ -n "$amfpid" ]; then
+
+if [ -e "$lockfile_inprogress" ]; then
+echo "Lockfile taken, OpenSAF start/stop is in 
progress"
+# LSB defines 150-199 as application reserved exit 
codes

+RETVAL=150
+elif [ -n "$amfpid" ]; then
  amf-state siass ha
  RETVAL=$?
  else





--
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] base: Improve state report for opensafd [#2459]

[Rafael Odzakow]

I don't agree with this suggestion having AMF in the status report of 
opensafd init script does not fit in here. AMF is not OpenSAF it is only 
a subset.


- Either have all services report status, or

- Have only the init script reports it internal status

The patch is avoiding this issue by creating a new return code because a 
real solution would be NBC. But as this script is pretty central to 
OpenSAF I am thinḱing NBC route would be better.



On 05/31/2017 12:42 PM, Hans Nordebäck wrote:

Hi Rafael,

not tested, but perhaps we can do this check instead?:

status() {

amfpid=`pidofproc -p $amfnd_pid $amfnd_bin`

if [[ -n "$amfpid" && ! -f "$lockfile_inprogress" ]; then
amf-state siass ha
RETVAL=$?
else
echo "The OpenSAF HA Framework is not running"
RETVAL=3
fi

return $RETVAL
}

/Hans


On 05/19/2017 12:46 PM, Rafael Odzakow wrote:

Internally opensafd creates a lock file during start/stop to avoid
parallel execution. To allow others to query the state this ticket will
use the opensafd lockfile to report the status of start/stop when
requested with "opensafd status"
---
  src/nid/opensafd.in | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in
index e7683bd7e..c93cca7e1 100644
--- a/src/nid/opensafd.in
+++ b/src/nid/opensafd.in
@@ -326,8 +326,14 @@ forcereload() {
  }
status() {
+
  amfpid=`pidofproc -p $amfnd_pid $amfnd_bin`
-if [ -n "$amfpid" ]; then
+
+if [ -e "$lockfile_inprogress" ]; then
+echo "Lockfile taken, OpenSAF start/stop is in 
progress"
+# LSB defines 150-199 as application reserved exit 
codes

+RETVAL=150
+elif [ -n "$amfpid" ]; then
  amf-state siass ha
  RETVAL=$?
  else






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

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

[Rafael Odzakow]

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 <rafael.odza...@ericsson.com>
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 threaded patch review.

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

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


--

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

[Rafael Odzakow]

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

diff --git a/src/smf/smfd/SmfUpgradeStep.cc b/src/smf/smfd/SmfUpgradeStep.cc
index 2ffeab1..fc54019 100644
--- a/src/smf/smfd/SmfUpgradeStep.cc
+++ b/src/smf/smfd/SmfUpgradeStep.cc
@@ -54,6 +54,7 @@
 #include "smf/smfd/SmfRollback.h"
 #include "smf/smfd/SmfUtils.h"
 #include "osaf/immutil/immutil.h"
+#include "osaf/configmake.h"
 #include "smf/smfd/smfd_smfnd.h"
 #include "smfd.h"
 #include "base/osaf_time.h"
@@ -2299,6 +2300,28 @@ bool SmfUpgradeStep::nodeReboot() {
   goto done;
 }
 
+// Try to make sure opensafd is not in startup phase otherwise reboot will
+// not trigger opensafd stop.
+int counter = 0;
+while (counter < 5) {
+  TRACE("checking status of opensafd");
+  std::string command = LSBINITDIR;
+  command += "/opensafd status";
+  cmdrc = smfnd_remote_cmd(command.c_str(), ,
+   cliTimeout, localTimeout);
+  if ((cmdrc  & 0x) == SMFSV_CMD_RESULT_CODE &&
+  (cmdrc & 0x) == 150) {
+  // The lockfile is taken, try again
+  LOG_WA("opensafd status, retcode[%u] retry in 2 seconds",
+ cmdrc & 0x);
+  struct timespec time = {2, 0};
+  osaf_nanosleep();
+  counter += 1;
+  } else {
+break;
+  }
+}
+
 /* When executing a reboot command on a node the command will never return
so we want a short local timeout. Since the smfnd is handling the
cli timeout we want that to be much longer so that the reboot command
diff --git a/src/smf/smfd/smfd_smfnd.c b/src/smf/smfd/smfd_smfnd.c
index 23770ef..7384637 100644
--- a/src/smf/smfd/smfd_smfnd.c
+++ b/src/smf/smfd/smfd_smfnd.c
@@ -55,8 +55,10 @@ static SaVersionT clmVersion = {'B', 1, 1};
 
 static pthread_mutex_t smfnd_list_lock = PTHREAD_MUTEX_INITIALIZER;
 
-static uint32_t smfnd_remote_cmd(const char *i_cmd, MDS_DEST i_smfnd_dest,
-uint32_t i_timeout);
+static uint32_t smfnd_legacy_remote_cmd(const char *i_cmd,
+MDS_DEST i_smfnd_dest,
+uint32_t i_timeout);
+void log_rsp_errors(const char *i_cmd, uint32_t i_timeout, uint32_t i_result);
 
 /* 
  *   FUNCTION PROTOTYPES
@@ -240,6 +242,23 @@ uint32_t smfnd_down(SaClmNodeIdT i_node_id)
 uint32_t smfnd_exec_remote_cmd(const char *i_cmd, const SmfndNodeDest *i_smfnd,
   uint32_t i_timeout, uint32_t i_localTimeout)
 {
+uint32_t result = smfnd_remote_cmd(i_cmd, i_smfnd, i_timeout,
+   i_localTimeout);
+log_rsp_errors(i_cmd, i_timeout, result);
+return result;
+}
+
+/**
+ * smfnd_remote_cmd
+ * @param i_cmd Remote command to be executed
+ * @param i_smfnd Info about the smfnd node where to execute
+ * the command
+ * @param i_timeout Max time the command may take in 10 ms
+ */
+uint32_t smfnd_remote_cmd(const char *i_cmd, const SmfndNodeDest *i_smfnd,
+  uint32_t i_timeout, uint32_t i_localTimeout)
+
+{
SMFSV_EVT cmd_req_asynch;
SMFSV_EVT *cmd_rsp = 0;
uint32_t rc;
@@ -270,7 +289,7 @@ uint32_t smfnd_exec_remote_cmd(const char *i_cmd, const 
SmfndNodeDest *i_smfnd,
if (i_smfnd->rem_svc_pvt_ver == 1) {
/* This addressed smfnd can only handle the old cmd req message
 * format */
-   return smfnd_remote_cmd(i_cmd, i_smfnd->dest, i_timeout);
+   return smfnd_legacy_remote_cmd(i_cmd, i_smfnd->dest, i_timeout);
}
 
/* A new smfnd can handle the asynch message */
@@ -297,53 +316,58 @@ uint32_t smfnd_exec_remote_cmd(const char *i_cmd, const 
SmfndNodeDest *i_smfnd,
return SMFSV_CMD_EXEC_FAILED;
}
 
-   if (cmd_rsp->info.smfd.event.cmd_rsp.result != 0) { /* 0 = cmd OK */
-   switch (cmd_rsp->info.smfd.event.cmd_rsp.result & 0x) {
-   case SMFSV_CMD_EXEC_FAILED: {
-   LOG_ER("Command %s failed to start (%u)", i_cmd,
-  

[devel] [PATCH 1/1] base: Improve state report for opensafd [#2459]

[Rafael Odzakow]

Internally opensafd creates a lock file during start/stop to avoid
parallel execution. To allow others to query the state this ticket will
use the opensafd lockfile to report the status of start/stop when
requested with "opensafd status"
---
 src/nid/opensafd.in | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in
index e7683bd7e..c93cca7e1 100644
--- a/src/nid/opensafd.in
+++ b/src/nid/opensafd.in
@@ -326,8 +326,14 @@ forcereload() {
 }
 
 status() {
+
amfpid=`pidofproc -p $amfnd_pid $amfnd_bin`
-   if [ -n "$amfpid" ]; then
+
+   if [ -e "$lockfile_inprogress" ]; then
+echo "Lockfile taken, OpenSAF start/stop is in progress"
+# LSB defines 150-199 as application reserved exit codes
+RETVAL=150
+elif [ -n "$amfpid" ]; then
amf-state siass ha
RETVAL=$?
else
-- 
2.11.0


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

[devel] [PATCH 0/1] Review Request for base: Improve state report for opensafd [#2459]

[Rafael Odzakow]

Summary: base: Improve state report for opensafd [#2459]
Review request for Ticket(s): 2459
Peer Reviewer(s): *** hans, anders
Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
Affected branch(es): develop
Development branch: ticket-2459
Base revision: 3327fbe68a0dfb978ba6ee316927d96381f42037
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 y
 SAF servicesn
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


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

revision 790dabad23cf7eab652dbb7ae5ea6052a3cccdf3
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Fri, 19 May 2017 12:39:40 +0200

base: Improve state report for opensafd [#2459]

Internally opensafd creates a lock file during start/stop to avoid
parallel execution. To allow others to query the state this ticket will
use the opensafd lockfile to report the status of start/stop when
requested with "opensafd status"



Complete diffstat:
--
 src/nid/opensafd.in | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)


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 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/1] base: Improve state report for opensafd [#2459]

[Rafael Odzakow]

The node is only allowed to be rebooted by the campaign during this 
scenario. In some rare cases SMF will reboot a node several times.

This problem is shows the message "opensafd start/stop already in 
progress". The follow up errors are not from opensafd but from services 
that can not handle a abrupt reboot.


On 05/17/2017 12:26 PM, Hans Nordebäck wrote:
> Hi Rafael,
>
> not sure if checking status of OpenSAF before ordering a reboot will 
> have any effect as the result
>
> of the call will only be momentarily accurate. Is the problem this 
> ticket address when SMF is ordering a
>
> reboot of a not fully started OpenSAF, and the "opensafd start/stop 
> already in progress" message in the syslog?
>
> If so, is this a problem, as a reboot has been ordered and will be 
> performed but without running opensafd stop?
>
> Perhaps we can change severity of the opensafd log messages instead?
>
> /Thanks HansN
>
>
> On 05/15/2017 03:56 PM, Rafael Odzakow wrote:
>> Internally opensafd creates a lock file during start/stop to avoid
>> parallel execution. To allow others to query the state this ticket will
>> use the opensafd lockfile to report the status of start/stop when
>> requested with "opensafd status"
>> ---
>>   src/nid/opensafd.in | 19 ++-
>>   1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in
>> index e7683bd7e..54841c372 100644
>> --- a/src/nid/opensafd.in
>> +++ b/src/nid/opensafd.in
>> @@ -12,6 +12,17 @@
>>   # Description: Start and stop the OpenSAF node
>>   ### END INIT INFO
>>   +# Exit codes:
>> +# 0: OK
>> +# 1: General error
>> +# 2: Argument error
>> +#
>> +# 'status' exit codes:
>> +# 0: OK
>> +# 1: AMF state error
>> +# 3: No AMF PID found
>> +# 4: Lockfile is taken, opensafd start/stop is in progress
>> +
>>   osafdirfile=@sysconfdir@/@PACKAGE_NAME@/osafdir.conf
>>   osafprog="opensafd"
>>   osafprog_inprogress="opensafd_inprogress"
>> @@ -326,9 +337,15 @@ forcereload() {
>>   }
>> status() {
>> +
>>   amfpid=`pidofproc -p $amfnd_pid $amfnd_bin`
>> -if [ -n "$amfpid" ]; then
>> +
>> +if [ -e "$lockfile_inprogress" ]; then
>> +echo "Lockfile taken, OpenSAF start/stop is in 
>> progress"
>> +RETVAL=4
>> +elif [ -n "$amfpid" ]; then
>>   amf-state siass ha
>> +# Two possible error codes: 0 or 1
>>   RETVAL=$?
>>   else
>>   echo "The OpenSAF HA Framework is not running"
>



--
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] base: Improve state report for opensafd [#2459]

[Rafael Odzakow]

Will do thanks.


On 05/17/2017 12:43 PM, Anders Widell wrote:
> The exit codes for an init script are defined by LSB:
>
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
>  
>
>
> so if we are going to touch the init scipt, I think we ought to align 
> the exit codes to the above specification.
>
> regards,
>
> Anders Widell
>
>
> On 05/17/2017 12:26 PM, Hans Nordebäck wrote:
>> Hi Rafael,
>>
>> not sure if checking status of OpenSAF before ordering a reboot will 
>> have any effect as the result
>>
>> of the call will only be momentarily accurate. Is the problem this 
>> ticket address when SMF is ordering a
>>
>> reboot of a not fully started OpenSAF, and the "opensafd start/stop 
>> already in progress" message in the syslog?
>>
>> If so, is this a problem, as a reboot has been ordered and will be 
>> performed but without running opensafd stop?
>>
>> Perhaps we can change severity of the opensafd log messages instead?
>>
>> /Thanks HansN
>>
>>
>> On 05/15/2017 03:56 PM, Rafael Odzakow wrote:
>>> Internally opensafd creates a lock file during start/stop to avoid
>>> parallel execution. To allow others to query the state this ticket will
>>> use the opensafd lockfile to report the status of start/stop when
>>> requested with "opensafd status"
>>> ---
>>>   src/nid/opensafd.in | 19 ++-
>>>   1 file changed, 18 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in
>>> index e7683bd7e..54841c372 100644
>>> --- a/src/nid/opensafd.in
>>> +++ b/src/nid/opensafd.in
>>> @@ -12,6 +12,17 @@
>>>   # Description: Start and stop the OpenSAF node
>>>   ### END INIT INFO
>>>   +# Exit codes:
>>> +# 0: OK
>>> +# 1: General error
>>> +# 2: Argument error
>>> +#
>>> +# 'status' exit codes:
>>> +# 0: OK
>>> +# 1: AMF state error
>>> +# 3: No AMF PID found
>>> +# 4: Lockfile is taken, opensafd start/stop is in progress
>>> +
>>>   osafdirfile=@sysconfdir@/@PACKAGE_NAME@/osafdir.conf
>>>   osafprog="opensafd"
>>>   osafprog_inprogress="opensafd_inprogress"
>>> @@ -326,9 +337,15 @@ forcereload() {
>>>   }
>>> status() {
>>> +
>>>   amfpid=`pidofproc -p $amfnd_pid $amfnd_bin`
>>> -if [ -n "$amfpid" ]; then
>>> +
>>> +if [ -e "$lockfile_inprogress" ]; then
>>> +echo "Lockfile taken, OpenSAF start/stop is in 
>>> progress"
>>> +RETVAL=4
>>> +elif [ -n "$amfpid" ]; then
>>>   amf-state siass ha
>>> +# Two possible error codes: 0 or 1
>>>   RETVAL=$?
>>>   else
>>>   echo "The OpenSAF HA Framework is not running"
>>
>
>



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

[devel] [PATCH 0/1] Review Request for base: Improve state report for opensafd [#2459]

[Rafael Odzakow]

Summary: base: Improve state report for opensafd [#2459]
Review request for Ticket(s): 2459
Peer Reviewer(s): anders/hans
Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
Affected branch(es): develop
Development branch: ticket-2459
Base revision: 8c09ce778f01cd0b202a2b7b9fd51dbc14648674
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 y
 SAF servicesn
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


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

revision 5e1e02e828aa6be52034fdf134456cffbd94e9b9
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Mon, 15 May 2017 15:49:13 +0200

base: Improve state report for opensafd [#2459]

Internally opensafd creates a lock file during start/stop to avoid
parallel execution. To allow others to query the state this ticket will
use the opensafd lockfile to report the status of start/stop when
requested with "opensafd status"



Complete diffstat:
--
 src/nid/opensafd.in | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)


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 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] base: Improve state report for opensafd [#2459]

[Rafael Odzakow]

Internally opensafd creates a lock file during start/stop to avoid
parallel execution. To allow others to query the state this ticket will
use the opensafd lockfile to report the status of start/stop when
requested with "opensafd status"
---
 src/nid/opensafd.in | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/src/nid/opensafd.in b/src/nid/opensafd.in
index e7683bd7e..54841c372 100644
--- a/src/nid/opensafd.in
+++ b/src/nid/opensafd.in
@@ -12,6 +12,17 @@
 # Description: Start and stop the OpenSAF node
 ### END INIT INFO
 
+# Exit codes:
+# 0: OK
+# 1: General error
+# 2: Argument error
+#
+# 'status' exit codes:
+# 0: OK
+# 1: AMF state error
+# 3: No AMF PID found
+# 4: Lockfile is taken, opensafd start/stop is in progress
+
 osafdirfile=@sysconfdir@/@PACKAGE_NAME@/osafdir.conf
 osafprog="opensafd"
 osafprog_inprogress="opensafd_inprogress"
@@ -326,9 +337,15 @@ forcereload() {
 }
 
 status() {
+
amfpid=`pidofproc -p $amfnd_pid $amfnd_bin`
-   if [ -n "$amfpid" ]; then
+
+   if [ -e "$lockfile_inprogress" ]; then
+echo "Lockfile taken, OpenSAF start/stop is in progress"
+RETVAL=4
+elif [ -n "$amfpid" ]; then
amf-state siass ha
+# Two possible error codes: 0 or 1
RETVAL=$?
else
echo "The OpenSAF HA Framework is not running"
-- 
2.11.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] smf: Expalain how osafAmfRestrictAutoRepairEnable setting in AMF affects SMF [#2379]

[Rafael Odzakow]

ACK, suggest to change trig to trigger.


On 05/04/2017 12:43 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]

[Rafael Odzakow]

ACK, not tested.


On 04/27/2017 03:10 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

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

[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

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

[Rafael Odzakow]

Summary: smf: cli-command does not wait for nodes to start [#1969]
Review request for Ticket(s): 1969
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
Development branch: ticket-1969
Private 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 servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


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

revision a424e48557e07052c0681b9a78d3b0d23bacb9a4
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Thu, 20 Apr 2017 15:11:08 +0200

smf: cli-command does not wait for nodes to start [#1969]

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



Complete diffstat:
--
 src/smf/smfd/SmfUpgradeAction.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 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 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] smfd: fix race condition when detecting async failures [#2413]

[Rafael Odzakow]

ACK


On 04/06/2017 08:26 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 smfd: fix race condition when detecting async failures [#2413]

[Rafael Odzakow]

Looks like some other code ended up in this patch?


On 04/06/2017 05:30 PM, Alex Jones wrote:
> Summary: smfd: fix race condition during campaign commit
> Review request for Trac Ticket(s): 2413
> Peer Reviewer(s): lennart, rafael, neel
> Pull request to:
> Affected branch(es): default
> Development branch:
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>
> changeset b51342e4460065d8a4416442e74f20d3db9c0a13
> Author:   Alex Jones 
> Date: Thu, 06 Apr 2017 11:22:19 -0400
>
>   smfd: fix race condition when detecting async failures [#2413]
>
>   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.)
>
>
> Complete diffstat:
> --
>   src/lck/Makefile.am   |8 +-
>   src/lck/agent/gla_api.c   |   96 +
>   src/lck/agent/gla_cb.h|4 +
>   src/lck/agent/gla_evt.h   |   11 +-
>   src/lck/agent/gla_init.c  |   26 +++
>   src/lck/agent/gla_mds.c   |   55 +++
>   src/lck/common/glsv_defs.h|9 +-
>   src/lck/lckd/gld_api.c|   27 +++-
>   src/lck/lckd/gld_cb.h |2 +-
>   src/lck/lckd/gld_evt.c|  105 +-
>   src/lck/lckd/gld_evt.h|   16 ++
>   src/lck/lckd/gld_rsc.c|8 +
>   src/lck/lcknd/glnd_agent.c|   22 +++
>   src/lck/lcknd/glnd_api.c  |   33 +++-
>   src/lck/lcknd/glnd_cb.c   |   10 +
>   src/lck/lcknd/glnd_cb.h   |   12 +
>   src/lck/lcknd/glnd_ckpt.c |   32 
>   src/lck/lcknd/glnd_client.c   |  175 +--
>   src/lck/lcknd/glnd_client.h   |   10 +
>   src/lck/lcknd/glnd_evt.c  |  268 
> ++---
>   src/lck/lcknd/glnd_mds.c  |   39 +
>   src/lck/lcknd/glnd_mds.h  |8 +
>   src/lck/lcknd/glnd_res.c  |   54 ++-
>   src/lck/lcknd/glnd_res_req.c  |   48 ++
>   src/lck/lcknd/glnd_restart.c  |   60 -
>   src/smf/smfd/SmfCampaignThread.cc |   16 +-
>   tools/cluster_sim_uml/opensaf |4 +-
>   27 files changed, 1014 insertions(+), 144 deletions(-)
>
>
> Testing Commands:
> -
> (1) run a campaign and let it get to completed state
> (2) commit and at the same time kill a component with suMaintenanceCampaign 
> set
>
> Testing, Expected Results:
> --
> smfd should not core
>
>
> 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.
>  

Re: [devel] [PATCH 0 of 1] Review Request for smf: retry of ccb operations when failed with resouce abort[#2389]

[Rafael Odzakow]

ACK, tested.

Had some issues but they were unrelated.


On 03/21/2017 01:36 PM, reddy.neelaka...@oracle.com wrote:
> Summary:smf: retry of ccb operations when failed with resouce abort[#2389]
> Review request for Trac Ticket(s): 2389
> Peer Reviewer(s): Rafael, Leenart
> Affected branch(es): 5.0.x, 5.1.x,default
> Development branch: defult
>
> 
> 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 6ffd3463b3f705e334e39ce8584006c7811f37f1
> Author:   Neelakanta Reddy 
> Date: Tue, 21 Mar 2017 18:00:36 +0530
>
>   smf: retry of ccb operations when failed with resouce abort[#2389]
>
>
> Complete diffstat:
> --
>   src/smf/smfd/SmfImmOperation.cc|  37 
> -
>   src/smf/smfd/SmfUpgradeCampaign.cc |   3 +--
>   src/smf/smfd/SmfUtils.cc   |  17 -
>   3 files changed, 53 insertions(+), 4 deletions(-)
>
>
> Testing Commands:
> -
> when the SMF upgrade is running, kill the IMMND in any node of the cluster
> which will lead to sync and aborts the ccb
>
> Testing, Expected Results:
> --
> SMF should TRY_AGAIN the ccb operation, if the ccb operation
> is failed/aborted with RESOUCE ABORT
>
> 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.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: retry of ccb operations when failed with resouce abort[#2389]

[Rafael Odzakow]

ACK, not tested


On 03/21/2017 01:36 PM, reddy.neelaka...@oracle.com wrote:
> Summary:smf: retry of ccb operations when failed with resouce abort[#2389]
> Review request for Trac Ticket(s): 2389
> Peer Reviewer(s): Rafael, Leenart
> Affected branch(es): 5.0.x, 5.1.x,default
> Development branch: defult
>
> 
> 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 6ffd3463b3f705e334e39ce8584006c7811f37f1
> Author:   Neelakanta Reddy 
> Date: Tue, 21 Mar 2017 18:00:36 +0530
>
>   smf: retry of ccb operations when failed with resouce abort[#2389]
>
>
> Complete diffstat:
> --
>   src/smf/smfd/SmfImmOperation.cc|  37 
> -
>   src/smf/smfd/SmfUpgradeCampaign.cc |   3 +--
>   src/smf/smfd/SmfUtils.cc   |  17 -
>   3 files changed, 53 insertions(+), 4 deletions(-)
>
>
> Testing Commands:
> -
> when the SMF upgrade is running, kill the IMMND in any node of the cluster
> which will lead to sync and aborts the ccb
>
> Testing, Expected Results:
> --
> SMF should TRY_AGAIN the ccb operation, if the ccb operation
> is failed/aborted with RESOUCE ABORT
>
> 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.org! http://sdm.link/slashdot
___
Opensaf-devel mailing list
Opensaf-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensaf-devel

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

[Rafael Odzakow]

 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, " +
+  "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, " +
+  "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

[devel] [PATCH 0 of 1] Review Request for smf: admin owner err_exist on parallel procedures [#2288]

[Rafael Odzakow]

Summary: smf: admin owner err_exist on parallel procedures [#2288]
Review request for Trac Ticket(s): #2288
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 servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


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

changeset a622485eda13b189e000b2b91ee8dd671b74ed7b
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Mon, 06 Feb 2017 15:53:03 +0100

smf: admin owner err_exist on parallel procedures [#2288]

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


Complete diffstat:
--
 src/smf/smfd/SmfImmOperation.cc |  22 +-
 src/smf/smfd/SmfUpgradeStep.cc  |  23 +--
 2 files changed, 42 insertions(+), 3 deletions(-)


Testing Commands:
-
 campaign example is in the ticket


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.


--
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: retry the ccb modify operation when the ccb is aborted with resource abort [#2277]

[Rafael Odzakow]

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?
>
> 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");
>>>

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

[Rafael Odzakow]

ACK, with comments after [rafael] tag

As an improvement after the retries the operation can fail the campaign. 
Today we only move the problem over to the next campaign?


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

[Rafael Odzakow]

Thanks, will fix.


On 01/09/2017 03:59 PM, Lennart Lund wrote:
> Hi Rafael
>
> Ack with comment. Not tested
>
> Comment: Move TRACE_ENTER(); to start of function
>
> Thanks
> Lennart
>
>> -----Original Message-
>> From: Rafael Odzakow
>> Sent: den 5 januari 2017 15:10
>> To: reddy.neelaka...@oracle.com; Lennart Lund
>> <lennart.l...@ericsson.com>
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: [PATCH 1 of 1] smf: failed one-step upgrade between opensaf
>> versions [#2226]
>>
>>   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

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

[Rafael Odzakow]

 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

[devel] [PATCH 0 of 1] Review Request for smf: failed one-step upgrade between opensaf versions [#2226]

[Rafael Odzakow]

Summary: smf: failed one-step upgrade between opensaf versions [#2226]
Review request for Trac Ticket(s): #2226
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 5d8c95fef7ccc995f353f49c9db1b6771ceba194
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Thu, 05 Jan 2017 13:34:07 +0100

smf: failed one-step upgrade between opensaf versions [#2226]


Complete diffstat:
--
 src/smf/smfd/SmfExecControlHdl.cc |  20 
 1 files changed, 16 insertions(+), 4 deletions(-)


Testing Commands:
-
 I did a reboot upgrade. Before the cluster rebooted I removed
"openSafSmfExecControl=SmfHdlCopy" with this change the campaign recreated the
copy after the reboot


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.


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

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

[Rafael Odzakow]

 src/smf/smfd/SmfExecControlHdl.cc |  17 -
 1 files changed, 12 insertions(+), 5 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,19 @@ bool SmfExecControlObjHandler::smfProtec
 bool SmfExecControlObjHandler::getValuesFromImmCopy() {
   bool errinfo = true;
 
+  std::string copydn = c_openSafSmfExecControl_copy;
+  if (!p_immutil_object->getObject(copydn, NULL)) {
+// We do not have a copy so create it. This can happen when upgrading from
+// an earlier version of SMF.
+install();
+  }
+
   TRACE_ENTER();
-if (readExecControlObject(c_openSafSmfExecControl_copy) == false) {
-  LOG_NO("%s readExecControlObject(c_openSafSmfExecControl_copy) Fail",
- __FUNCTION__);
-  errinfo = false;
-}
+  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

[devel] [PATCH 0 of 1] Review Request for smf: failed one-step upgrade between opensaf versions [#2226]

[Rafael Odzakow]

Summary: smf: failed one-step upgrade between opensaf versions [#2226]
Review request for Trac Ticket(s): #2226
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 a0c0ea48b46d897826374d92e1a5a990d8e59e04
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Thu, 05 Jan 2017 13:34:07 +0100

smf: failed one-step upgrade between opensaf versions [#2226]


Complete diffstat:
--
 src/smf/smfd/SmfExecControlHdl.cc |  17 -
 1 files changed, 12 insertions(+), 5 deletions(-)


Testing Commands:
-
 I did a reboot upgrade. Before the cluster rebooted I removed
 "openSafSmfExecControl=SmfHdlCopy" with this change the campaign recreated the
 copy after the reboot


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.


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

[devel] [PATCH 1 of 1] smf: builds on ubuntu 16.04 cause segmentation fault [#2242]

[Rafael Odzakow]

 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |  6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)


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
@@ -2002,10 +2002,14 @@ SmfUpgradeProcedure::addStepModification
SaImmAttrValuesT_2 **attributes;
std::list < std::string > objectList;
std::list < std::string >::const_iterator objit;
-   const std::string & auNodeName = 
i_newStep->getActivationUnitList().front().name;
+   std::string auNodeName = "";
std::multimap::iterator iter;
std::pair::iterator, 
std::multimap::iterator> nodeName_mm;
 
+if (i_newStep->getActivationUnitList().size() > 0) {
+auNodeName = i_newStep->getActivationUnitList().front().name;
+}
+
nodeName_mm = i_objects.equal_range(auNodeName);
 
std::string typeDn   = i_parentType->getTypeDn();

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

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

[Rafael Odzakow]

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 <rafael.odza...@ericsson.com>
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 smf: For a step, allow all unit types in the unit list [#2125]

[Rafael Odzakow]

ACK no comments


On 12/09/2016 11:58 AM, Lennart Lund wrote:
> Summary: smf: For a step, allow all unit types in the unit list
> Review request for Trac Ticket(s): #2125
> Peer Reviewer(s): rafael.odza...@ericsson.com, reddy.neelaka...@oracle.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):
> -
>   <>
>
> changeset 50fa6ce8427607ed651de08d63db64f02a4d82d0
> Author:   Lennart Lund 
> Date: Thu, 08 Dec 2016 14:06:36 +0100
>
>   smf: For a step, allow all unit types in the unit list [#2125]
>
>   Make the SmfAdminOperation class able to handle an all unit list that
>   contains a mix of all types of units e.i SU, Node and Component. Ignore 
> unit
>   types that are not compatible with the requested operation
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  23 ++-
>   1 files changed, 18 insertions(+), 5 deletions(-)
>
>
> Testing Commands:
> -
> Run legacy tests
>
>
> 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 1 of 1] smf: use IMM appler for the change in longDnsAllowed attributes [#2139]

[Rafael Odzakow]

ACK with comments.


On 12/08/2016 10:22 AM, Lennart Lund wrote:
>   osaf/services/saf/smfsv/README|   34 +-
>   osaf/services/saf/smfsv/smfd/Makefile.am  |   13 +-
>   osaf/services/saf/smfsv/smfd/SmfCampaign.cc   |5 +-
>   osaf/services/saf/smfsv/smfd/SmfCampaignInit.cc   |6 -
>   osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc |   13 +-
>   osaf/services/saf/smfsv/smfd/SmfImmApplierHdl.cc  |  726 
> ++
>   osaf/services/saf/smfsv/smfd/SmfImmApplierHdl.hh  |  113 +++
>   osaf/services/saf/smfsv/smfd/SmfImmOperation.cc   |   15 +-
>   osaf/services/saf/smfsv/smfd/SmfLongDnApplier.cc  |  441 +
>   osaf/services/saf/smfsv/smfd/SmfLongDnApplier.hh  |   84 ++
>   osaf/services/saf/smfsv/smfd/SmfUtils.cc  |   83 +--
>   osaf/services/saf/smfsv/smfd/SmfUtils.hh  |7 -
>   osaf/services/saf/smfsv/smfd/smfd.h   |2 +-
>   osaf/services/saf/smfsv/smfd/smfd_amf.c   |   20 +-
>   osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc  |   18 -
>   osaf/services/saf/smfsv/smfd/smfd_cb.h|3 +-
>   osaf/services/saf/smfsv/smfd/smfd_evt.h   |7 +
>   osaf/services/saf/smfsv/smfd/smfd_long_dn.hh  |   58 +
>   osaf/services/saf/smfsv/smfd/smfd_main.c  |   13 +-
>   19 files changed, 1530 insertions(+), 131 deletions(-)
>
>
> Keep track of long DN setting using an IMM applier instead of reading
> the long DN setting in many places
>
> diff --git a/osaf/services/saf/smfsv/README b/osaf/services/saf/smfsv/README
> --- a/osaf/services/saf/smfsv/README
> +++ b/osaf/services/saf/smfsv/README
> @@ -251,6 +251,38 @@ directory "samples/smfsv"
>   CONTRIBUTORS/MAINTAINERS
>   
>   Bertil Engelholm 
> -Ingvar Bergstr?m 
> +Ingvar Bergstr???m 
>   
>   The SMF service was originally cloned from the immsv and log services.
> +
> +MAINTAINER NOTES
> +
> +
> +Applier for monitoring long Dn allowed setting
> +--
> +SMF is dependent on knowing the longDnsAllowed setting in the IMM 
> configuration
> +object. This setting may change at any time and to monitor changes an IMM
> +applier is used.
> +
> +SmfImmApplierHdl:
> +Contains a wrapper for the IMM APIs and callback functions used with an 
> applier.
> +A C++ class is used to create an interface for handling an applier e.g. 
> create,
> +start (initialize and set), stop (clear), get value etc.
> +See SmfImmApplierHdl.hh for more information.
> +
> +SmfLongDnApplier:
> +Runs an applier in a thread using the SmfImmApplierHdl.
> +A C++ class is used to create an interface for running an applier.
> +See SmfLongDnApplier.hh for more information.
> +
> +Installation in SMF:
> +
> +In smfd_main.cc the applier is constructed and created. A pointer to the 
> applier
> +object is stored in a global variable. The applier is started and stopped in 
> the
> +same place as the SMF object implementer when SMF gets a CSI set callback, 
> see
> +smfd_amf.cc. In previous versions of SMF a global variable in the smfd_cb 
> struct
> +, maxDnLength, was used to store the maximum allowed length of a Dn 
> depending on
> +the IMM config long Dn setting. This length information is used in many 
> places
> +in the SMF code. The global variable is replaced by a function call to
> +GetSmfMaxDnLength() which returns the same length information. This function
> +can be found in smfd_long_dn.hh
> diff --git a/osaf/services/saf/smfsv/smfd/Makefile.am 
> b/osaf/services/saf/smfsv/smfd/Makefile.am
> --- a/osaf/services/saf/smfsv/smfd/Makefile.am
> +++ b/osaf/services/saf/smfsv/smfd/Makefile.am
> @@ -51,7 +51,10 @@ noinst_HEADERS = \
>   SmfCallback.hh \
>   SmfCbkUtil.hh \
>   SmfExecControl.h \
> - SmfExecControlHdl.h
> + SmfExecControlHdl.h \
> + SmfLongDnApplier.hh \
> + SmfImmApplierHdl.hh \
> + smfd_long_dn.hh
>   
>   osafsmfd_CXXFLAGS = $(AM_CXXFLAGS) @XML2_CFLAGS@
>   
> @@ -63,9 +66,9 @@ osafsmfd_CPPFLAGS = \
>   -I$(top_srcdir)/osaf/tools/saflog/include
>   
>   osafsmfd_SOURCES = \
> - smfd_amf.c \
> + smfd_amf.cc \
>   smfd_evt.c \
> - smfd_main.c \
> + smfd_main.cc \
>   smfd_smfnd.c \
>   smfd_mds.c \
>   SmfCampaignThread.cc \
> @@ -91,7 +94,9 @@ osafsmfd_SOURCES = \
>   SmfCallback.cc \
>   SmfCbkUtil.cc \
>   SmfExecControl.cc \
> - SmfExecControlHdl.cc
> + SmfExecControlHdl.cc \
> + SmfLongDnApplier.cc \
> + SmfImmApplierHdl.cc
>   
>   osafsmfd_LDFLAGS = \
>   $(AM_LDFLAGS) \
> diff --git a/osaf/services/saf/smfsv/smfd/SmfCampaign.cc 
> b/osaf/services/saf/smfsv/smfd/SmfCampaign.cc
> --- a/osaf/services/saf/smfsv/smfd/SmfCampaign.cc
> +++ b/osaf/services/saf/smfsv/smfd/SmfCampaign.cc
> @@ -34,6 +34,7 @@
>   #include "SmfUpgradeAction.hh"
>   #include "SmfUtils.hh"
>   #include 

Re: [devel] [PATCH 1 of 1] smf: use IMM appler for the change in longDnsAllowed attributes [#2139]

[Rafael Odzakow]

Still not completed the review. Check comments inline


On 12/08/2016 10:22 AM, Lennart Lund wrote:
>   osaf/services/saf/smfsv/README|   34 +-
>   osaf/services/saf/smfsv/smfd/Makefile.am  |   13 +-
>   osaf/services/saf/smfsv/smfd/SmfCampaign.cc   |5 +-
>   osaf/services/saf/smfsv/smfd/SmfCampaignInit.cc   |6 -
>   osaf/services/saf/smfsv/smfd/SmfCampaignThread.cc |   13 +-
>   osaf/services/saf/smfsv/smfd/SmfImmApplierHdl.cc  |  726 
> ++
>   osaf/services/saf/smfsv/smfd/SmfImmApplierHdl.hh  |  113 +++
>   osaf/services/saf/smfsv/smfd/SmfImmOperation.cc   |   15 +-
>   osaf/services/saf/smfsv/smfd/SmfLongDnApplier.cc  |  441 +
>   osaf/services/saf/smfsv/smfd/SmfLongDnApplier.hh  |   84 ++
>   osaf/services/saf/smfsv/smfd/SmfUtils.cc  |   83 +--
>   osaf/services/saf/smfsv/smfd/SmfUtils.hh  |7 -
>   osaf/services/saf/smfsv/smfd/smfd.h   |2 +-
>   osaf/services/saf/smfsv/smfd/smfd_amf.c   |   20 +-
>   osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc  |   18 -
>   osaf/services/saf/smfsv/smfd/smfd_cb.h|3 +-
>   osaf/services/saf/smfsv/smfd/smfd_evt.h   |7 +
>   osaf/services/saf/smfsv/smfd/smfd_long_dn.hh  |   58 +
>   osaf/services/saf/smfsv/smfd/smfd_main.c  |   13 +-
>   19 files changed, 1530 insertions(+), 131 deletions(-)
>
>
> Keep track of long DN setting using an IMM applier instead of reading
> the long DN setting in many places
>
> diff --git a/osaf/services/saf/smfsv/README b/osaf/services/saf/smfsv/README
> --- a/osaf/services/saf/smfsv/README
> +++ b/osaf/services/saf/smfsv/README
> @@ -251,6 +251,38 @@ directory "samples/smfsv"
>   CONTRIBUTORS/MAINTAINERS
>   
>   Bertil Engelholm 
> -Ingvar Bergstr?m 
> +Ingvar Bergstr???m 
>   
>   The SMF service was originally cloned from the immsv and log services.
> +
> +MAINTAINER NOTES
> +
> +
> +Applier for monitoring long Dn allowed setting
> +--
> +SMF is dependent on knowing the longDnsAllowed setting in the IMM 
> configuration
> +object. This setting may change at any time and to monitor changes an IMM
> +applier is used.
> +
> +SmfImmApplierHdl:
> +Contains a wrapper for the IMM APIs and callback functions used with an 
> applier.
> +A C++ class is used to create an interface for handling an applier e.g. 
> create,
> +start (initialize and set), stop (clear), get value etc.
> +See SmfImmApplierHdl.hh for more information.
> +
> +SmfLongDnApplier:
> +Runs an applier in a thread using the SmfImmApplierHdl.
> +A C++ class is used to create an interface for running an applier.
> +See SmfLongDnApplier.hh for more information.
> +
> +Installation in SMF:
> +
> +In smfd_main.cc the applier is constructed and created. A pointer to the 
> applier
> +object is stored in a global variable. The applier is started and stopped in 
> the
> +same place as the SMF object implementer when SMF gets a CSI set callback, 
> see
> +smfd_amf.cc. In previous versions of SMF a global variable in the smfd_cb 
> struct
> +, maxDnLength, was used to store the maximum allowed length of a Dn 
> depending on
> +the IMM config long Dn setting. This length information is used in many 
> places
> +in the SMF code. The global variable is replaced by a function call to
> +GetSmfMaxDnLength() which returns the same length information. This function
> +can be found in smfd_long_dn.hh
> diff --git a/osaf/services/saf/smfsv/smfd/Makefile.am 
> b/osaf/services/saf/smfsv/smfd/Makefile.am
> --- a/osaf/services/saf/smfsv/smfd/Makefile.am
> +++ b/osaf/services/saf/smfsv/smfd/Makefile.am
> @@ -51,7 +51,10 @@ noinst_HEADERS = \
>   SmfCallback.hh \
>   SmfCbkUtil.hh \
>   SmfExecControl.h \
> - SmfExecControlHdl.h
> + SmfExecControlHdl.h \
> + SmfLongDnApplier.hh \
> + SmfImmApplierHdl.hh \
> + smfd_long_dn.hh
>   
>   osafsmfd_CXXFLAGS = $(AM_CXXFLAGS) @XML2_CFLAGS@
>   
> @@ -63,9 +66,9 @@ osafsmfd_CPPFLAGS = \
>   -I$(top_srcdir)/osaf/tools/saflog/include
>   
>   osafsmfd_SOURCES = \
> - smfd_amf.c \
> + smfd_amf.cc \
>   smfd_evt.c \
> - smfd_main.c \
> + smfd_main.cc \
>   smfd_smfnd.c \
>   smfd_mds.c \
>   SmfCampaignThread.cc \
> @@ -91,7 +94,9 @@ osafsmfd_SOURCES = \
>   SmfCallback.cc \
>   SmfCbkUtil.cc \
>   SmfExecControl.cc \
> - SmfExecControlHdl.cc
> + SmfExecControlHdl.cc \
> + SmfLongDnApplier.cc \
> + SmfImmApplierHdl.cc
>   
>   osafsmfd_LDFLAGS = \
>   $(AM_LDFLAGS) \
> diff --git a/osaf/services/saf/smfsv/smfd/SmfCampaign.cc 
> b/osaf/services/saf/smfsv/smfd/SmfCampaign.cc
> --- a/osaf/services/saf/smfsv/smfd/SmfCampaign.cc
> +++ b/osaf/services/saf/smfsv/smfd/SmfCampaign.cc
> @@ -34,6 +34,7 @@
>   #include "SmfUpgradeAction.hh"
>   

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

[Rafael Odzakow]

Reviewed, ACK from me.


On 12/02/2016 11:52 AM, 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 
> 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.
>


--
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] smfd: add support for asynchronous detection of failed AMF entities [#2145]

[Rafael Odzakow]

I can add that campaigns without this change will not detect a crash. 
But if any operations are to be done against the object after the fact 
they would fail and cause a rollback of the campaign. So we end up with 
two different behaviors one that suspends the campaign and another that 
rolls it back.


On 11/15/2016 08:28 AM, Neelakanta Reddy wrote:
> 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 <lennart.l...@ericsson.com>;
>>>> reddy.neelaka...@oracle.com; Rafael Odzakow
>>>> <rafael.odza...@ericsson.com>
>>>> Cc: opensaf-devel@lists.sourceforge.net
>>> <mailto: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

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

[Rafael Odzakow]

ACK


On 11/15/2016 09:37 AM, 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 0 of 1] Review Request for smf: Fix loop timeout in admin operation handling [#2066]

[Rafael Odzakow]

ACK


On 10/28/2016 10:54 AM, 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
___
Opensaf-devel mailing list

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

[Rafael Odzakow]

ACK


On 11/07/2016 01:12 PM, Lennart Lund wrote:
> Summary: smf: Fails to create a node group, admin owner/handle is lost
> Review request for Trac Ticket(s): #2153
> Peer Reviewer(s): rafael.odza...@ericsson.com, reddy.neelaka...@oracle.com
> Pull request to:
> Affected branch(es): 5.1 ->
> 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 c693485eac53ec9792c067f9815fe93f99c5baa3
> Author:   Lennart Lund 
> Date: Fri, 04 Nov 2016 13:42:29 +0100
>
>   smf: Fails to create a node group, admin owner/handle is lost [#2153]
>
>   Recreate handles and admin owner if creating a node group fail
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  46 
> +++---
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh |   1 +
>   2 files changed, 36 insertions(+), 11 deletions(-)
>
>
> Testing Commands:
> -
> Intermittent problem. Campaign with nodes as deacivation/activation units
> may fail because of BAD HANDLE or BAD OPERATION when creating a node group.
> Run such a campaign many times
>
>
> Testing, Expected Results:
> --
> Sahll never fail as described above
>
>
> Conditions of Submission:
> -
> Will be pushed after one week or ack from all 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

[devel] Review request for SMF PR document [#2152]

[Rafael Odzakow]

document attached in ticket.

https://sourceforge.net/p/opensaf/tickets/2152/


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

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

[Rafael Odzakow]

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 <rafael.odza...@ericsson.com>
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.


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

[devel] [PATCH 1 of 1] smf:balanced upgrade, no activation/deactivation done [#2126]

[Rafael Odzakow]

 osaf/services/saf/smfsv/smfd/SmfExecControl.cc |  21 +++--
 1 files changed, 11 insertions(+), 10 deletions(-)


Add the deactivation list to the balanced procedure, it was declared but not
used.

diff --git a/osaf/services/saf/smfsv/smfd/SmfExecControl.cc 
b/osaf/services/saf/smfsv/smfd/SmfExecControl.cc
--- a/osaf/services/saf/smfsv/smfd/SmfExecControl.cc
+++ b/osaf/services/saf/smfsv/smfd/SmfExecControl.cc
@@ -35,8 +35,8 @@ static std::vector getS
 static SmfUpgradeStep* mergeStep(SmfUpgradeProcedure* procedure,
  const std::vector& steps);
 
-static bool removeDuplicateActivationUnits(SmfUpgradeProcedure * i_newproc,
-   SmfUpgradeStep *newStep);
+static bool removeDuplicateActivationUnits(SmfUpgradeProcedure * i_newproc, 
SmfUpgradeStep *newStep,
+   const std::list& 
deact);
 
 
 static bool isNodeInGroup(const std::string& node,
@@ -104,14 +104,18 @@ bool createStepForBalancedProc(SmfUpgrad
   SmfUpgradeCampaign* ucamp = camp->getUpgradeCampaign();
 
   auto steps = getStepsMatchingBalancedGroup(procedure, ucamp);
+  std::list  deact;
   for (auto step : steps) {
 SmfUpgradeProcedure* oproc = step->getProcedure();
 // copy callbacks to the new procedure
 procedure->getCallbackList(oproc->getUpgradeMethod());
+deact.insert(deact.end(),
+ step->getDeactivationUnitList().begin(),
+ step->getDeactivationUnitList().end());
   }
   if (!steps.empty()) {
 SmfUpgradeStep* newstep = mergeStep(procedure, steps);
-removeDuplicateActivationUnits(procedure, newstep);
+removeDuplicateActivationUnits(procedure, newstep, deact);
 procedure->addProcStep(newstep);
   }
   const std::vector& allprocs = ucamp->getProcedures();
@@ -201,15 +205,11 @@ SmfUpgradeStep* mergeStep(SmfUpgradeProc
   newstep->setDn(newstep->getRdn() + "," + procedure->getDn());
   newstep->setMaxRetry(0);
   newstep->setRestartOption(0);
-  std::list  deact;
   for (auto step : steps) {
 if (isNodeInGroup(step->getSwNode(), procedure->getBalancedGroup())) {
-  TRACE("adding modifications, deact and bundle ref from node:%s",
+  TRACE("adding modifications and bundle ref from node:%s",
 step->getSwNode().c_str());
   newstep->addModifications(step->getModifications());
-  deact.insert(deact.end(),
-   step->getDeactivationUnitList().begin(),
-   step->getDeactivationUnitList().end());
   procedure->mergeBundleRefRollingToSingleStep(newstep, step);
 }
   }
@@ -217,13 +217,14 @@ SmfUpgradeStep* mergeStep(SmfUpgradeProc
   return newstep;
 }
 
-bool removeDuplicateActivationUnits(SmfUpgradeProcedure * i_newproc,
-SmfUpgradeStep *newStep) {
+bool removeDuplicateActivationUnits(SmfUpgradeProcedure * i_newproc, 
SmfUpgradeStep *newStep,
+const std::list& deact) {
   // Remove any (de)activation unit duplicates and add them to the step.
   // Activation and deactivation units are the same because rolling and
   // formodify is symetric.
   TRACE_ENTER();
   std::list < unitNameAndState > tmpDU;
+  tmpDU.insert(tmpDU.begin(), deact.begin(), deact.end());
   std::multimap objInstances;
   if (i_newproc->getImmComponentInfo(objInstances) == false) {
 TRACE("Config info from IMM could not be read");

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

[Rafael Odzakow]

ACK


On 10/28/2016 10:42 AM, Neelakanta Reddy wrote:
> 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:
> 
> 
>  operation="SA_IMM_ATTR_VALUES_REPLACE" 
> objectDN="opensafImm=opensafImm,safApp=safImmService">
>  name="longDnsAllowed" type="SA_IMM_ATTR_SAUINT32T">
> 1
> 
> 
> 
> 
> 
> 
>  objectClassName="OpenSafSmfMisc" parentObjectDN="=">
>  name="openSafSmfMisc" type="SA_IMM_ATTR_SASTRINGT">
> openSafSmfMisc=ThisIsA300CharLongRDNaa
>  
>
> 
>  type="SA_IMM_ATTR_SASTRINGT">
> 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

[devel] [PATCH 0 of 1] Review Request for smf: balanced upgrade, modifications missing after reboot [#2147]

[Rafael Odzakow]

Summary: smf: balanced upgrade, modifications missing after reboot [#2147]
Review request for Trac Ticket(s): #2147
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 servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


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

changeset 156841c1d9ae46d23fb12fdcc3f206e28abfbaa9
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Fri, 28 Oct 2016 12:14:53 +0200

smf: balanced upgrade, modifications missing after reboot [#2147]

The issue happens duing balanced upgrade when doing an SI SWAP on the
controllers just before starting the balanced procedures. In this case 
SMF
normally would read the IMM data for any step modifications ticket 
[#906]
changed that to not read any modifications when the procedures are in
COMPLETE state. Solution is to keep the behaviour in a non balanced 
upgrade.
When executing a balanced upgrade the modifications are read and a error
check (forAddRemove and forModify) is skipped.


Complete diffstat:
--
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |  23 
+++
 1 files changed, 15 insertions(+), 8 deletions(-)


Testing Commands:
-
  have a rolling procedure execute on the controllers just before starting bisu.
  The software bundles included in the bisu upgrade should reqire a reboot.


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.


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

[devel] [PATCH 1 of 1] smf: balanced upgrade, modifications missing after reboot [#2147]

[Rafael Odzakow]

 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |  23 +---
 1 files changed, 15 insertions(+), 8 deletions(-)


The issue happens duing balanced upgrade when doing an SI SWAP on the
controllers just before starting the balanced procedures. In this case SMF
normally would read the IMM data for any step modifications ticket [#906]
changed that to not read any modifications when the procedures are in COMPLETE
state. Solution is to keep the behaviour in a non balanced upgrade. When
executing a balanced upgrade the modifications are read and a error check
(forAddRemove and forModify) is skipped.

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
@@ -1913,9 +1913,13 @@ SmfUpgradeProcedure::addStepModification
 //Skip this for procedures in state completed, modifications will not 
be needed if completed.
 //This can happend if the cluster is rebooted and will fail if the 
reboot is performed when the 
 //versioned types are removed i.e. during test traffic, if the types 
was removed in campaign wrapup/complete section.
-if (getState() == SA_SMF_PROC_COMPLETED) {
-TRACE_LEAVE();
-return true;
+SmfUpgradeCampaign* ucamp = 
SmfCampaignThread::instance()->campaign()->getUpgradeCampaign();
+if (ucamp->getProcExecutionMode() != SMF_BALANCED_MODE) {
+if (getState() == SA_SMF_PROC_COMPLETED) {
+TRACE("Procedure is completed, skipping 
addStepModifications");
+TRACE_LEAVE();
+return true;
+}
 }
 
std::list < SmfTargetEntityTemplate * >::const_iterator it;
@@ -3027,11 +3031,14 @@ SmfUpgradeProcedure::getImmStepsSingleSt
const SmfForAddRemove* forAddRemove = dynamic_cast(scope);
const SmfForModify*forModify= dynamic_cast(scope);
 
-if ((forAddRemove == NULL)&&(forModify == NULL)) {
-   LOG_NO("SmfUpgradeProcedure::getImmStepsSingleStep: Procedure 
scope not found (SmfForAddRemove/forModify)");
-delete newStep;
-   TRACE_LEAVE();
-   return SA_AIS_ERR_NOT_EXIST;
+SmfUpgradeCampaign* ucamp = 
SmfCampaignThread::instance()->campaign()->getUpgradeCampaign();
+if (ucamp->getProcExecutionMode() != SMF_BALANCED_MODE) {
+if ((forAddRemove == NULL)&&(forModify == NULL)) {
+LOG_NO("Procedure scope not found 
(SmfForAddRemove/forModify)");
+delete newStep;
+TRACE_LEAVE();
+return SA_AIS_ERR_NOT_EXIST;
+}
 }
 
//--

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

[Rafael Odzakow]

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.
> +
>   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?
> + 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 0 of 1] Review Request for smf: Admin owner set needed if new handles has been created [#2122]

[Rafael Odzakow]

ACK


On 10/18/2016 03:54 PM, Lennart Lund wrote:
> Summary: smf: Admin owner set needed if new handles has been created
> Review request for Trac Ticket(s): #2122
> Peer Reviewer(s): rafael.odza...@ericsson.com
> Pull request to:
> Affected branch(es): 5.1 and devel
> 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 79ffb701265c7ebea1fc48d04679e19c311f7e12
> Author:   Lennart Lund 
> Date: Tue, 18 Oct 2016 15:41:52 +0200
>
>   smf: Admin owner set needed if new handles has been created [#2122]
>
>   If not the same handles are used for creating and deleting a node group
>   (e.g. bad handle error) saImmOmAdminOwnerSet must be used to connect the
>   node group with the new admin owner
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  103 
> +--
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh |5 ++-
>   2 files changed, 66 insertions(+), 42 deletions(-)
>
>
> Testing Commands:
> -
> Create a node group named as the temporary node groug used by lock handling
> before running a single step campaign with nodes as deactivation/activation
> units.
>
> Command for creating the node group:
> immcfg -c SaAmfNodeGroup -a saAmfNGAdminState=2 -a 
> saAmfNGNodeList='safAmfNode=PL-3,safAmfCluster=myAmfCluster' 
> safAmfNodeGroup=smfLockAdmNg1,safAmfCluster=myAmfCluster
>
>
> Testing, Expected Results:
> --
> With patch the campaign shall complete
>
>
> Conditions of Submission:
> -
> Push end of week after ack from reviwer
>
>
> 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.
>

[devel] [PATCH 1 of 1] smf: balanced upgrade, missing removal of exectrl copy [#2114]

[Rafael Odzakow]

 osaf/services/saf/smfsv/smfd/SmfExecControlHdl.cc  |  69 ++---
 osaf/services/saf/smfsv/smfd/SmfExecControlHdl.h   |  13 +--
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc |   1 +
 3 files changed, 51 insertions(+), 32 deletions(-)


diff --git a/osaf/services/saf/smfsv/smfd/SmfExecControlHdl.cc 
b/osaf/services/saf/smfsv/smfd/SmfExecControlHdl.cc
--- a/osaf/services/saf/smfsv/smfd/SmfExecControlHdl.cc
+++ b/osaf/services/saf/smfsv/smfd/SmfExecControlHdl.cc
@@ -41,7 +41,10 @@ SmfExecControlObjHandler::SmfExecControl
   m_exec_ctrl_name_ad(0),
   m_procExecMode_ad(0),
   m_numberOfSingleSteps_ad(0),
-  m_nodesForSingleStep_ad(0)
+  m_nodesForSingleStep_ad(0),
+  m_omHandle(0),
+  m_ownerHandle(0),
+  m_ccbHandle(0)
 {
   p_immutil_object = new SmfImmUtils; // Deleted by uninstall and in destructor
 }
@@ -57,8 +60,10 @@ SmfExecControlObjHandler::~SmfExecContro
   // overwritten the next time a copy has to be created
   //
   TRACE_ENTER();
-  if (p_immutil_object != 0)
+  if (p_immutil_object != NULL) {
 delete p_immutil_object;
+p_immutil_object = NULL;
+  }
   TRACE_LEAVE();
 }
 
@@ -94,8 +99,10 @@ bool SmfExecControlObjHandler::install()
 
 void SmfExecControlObjHandler::uninstall() {
   TRACE_ENTER();
-  if (p_immutil_object != 0)
+  if (p_immutil_object != NULL) {
 delete p_immutil_object;
+p_immutil_object = NULL;
+  }
   removeExecControlObjectCopy();
   TRACE_LEAVE();
 }
@@ -311,6 +318,20 @@ void SmfExecControlObjHandler::removeExe
 
   TRACE("Deleting object '%s'", c_openSafSmfExecControl_copy);
 
+  if (createImmOmHandles() == false) {
+TRACE("createCcbHandle Fail");
+  }
+
+  const SaNameT *names[2];
+  names[0] = _name;
+  names[1] = NULL;
+  ais_rc = immutil_saImmOmAdminOwnerSet(m_ownerHandle, names, SA_IMM_ONE);
+
+  if (ais_rc != SA_AIS_OK) {
+LOG_NO("%s - saImmOmAdminOwnerSet FAILED: %s",
+   __FUNCTION__, saf_error(ais_rc));
+  }
+
   ais_rc = immutil_saImmOmCcbObjectDelete(m_ccbHandle,
   _name);
   if (ais_rc != SA_AIS_OK) {
@@ -325,6 +346,8 @@ void SmfExecControlObjHandler::removeExe
   }
   }
 
+  finalizeImmOmHandles();
+
   TRACE_LEAVE();
 }
 
@@ -344,10 +367,8 @@ bool SmfExecControlObjHandler::copyExecC
   // 
   // Create handles needed
   //
-  rc = createAllImmHandles();
-  if (rc == false) {
-LOG_NO("%s: createAllImmHandles Fail", __FUNCTION__);
-return rc;
+  if (createImmOmHandles() == false) {
+TRACE("createCcbHandle Fail");
   }
 
   // 
@@ -398,6 +419,7 @@ bool SmfExecControlObjHandler::copyExecC
 }
   }
 
+  finalizeImmOmHandles();
   TRACE_LEAVE();
   return rc;
 }
@@ -428,7 +450,7 @@ void SmfExecControlObjHandler::saveAttri
  * 
  * @return false on Fail
  */
-bool SmfExecControlObjHandler::createAllImmHandles() {
+bool SmfExecControlObjHandler::createImmOmHandles() {
   SaAisErrorT ais_rc = SA_AIS_ERR_TRY_AGAIN;
   int timeout_try_cnt = 6;
   bool rc = true;
@@ -448,23 +470,6 @@ bool SmfExecControlObjHandler::createAll
 rc = false;
   }
 
-  // Accessors handle
-  if (rc == true) {
-timeout_try_cnt = 6;
-while (timeout_try_cnt > 0) {
-  ais_rc = immutil_saImmOmAccessorInitialize(m_omHandle,
- _accessorHandle);
-  if (ais_rc != SA_AIS_ERR_TIMEOUT)
-break;
-  timeout_try_cnt--;
-}
-if (ais_rc != SA_AIS_OK) {
-  LOG_NO("%s: saImmOmAccessorInitialize Fail %s",
- __FUNCTION__, saf_error(ais_rc));
-  rc = false;
-}
-  }
-
   // Admin owner handle
   if (rc == true) {
 timeout_try_cnt = 6;
@@ -504,3 +509,17 @@ bool SmfExecControlObjHandler::createAll
   TRACE_LEAVE();
   return rc;
 }
+
+void SmfExecControlObjHandler::finalizeImmOmHandles() {
+  if (m_omHandle != 0) {
+SaAisErrorT ais_rc = immutil_saImmOmFinalize(m_omHandle);
+if (ais_rc != SA_AIS_OK) {
+  LOG_NO("%s: immutil_saImmOmFinalize Fail %s",
+ __FUNCTION__, saf_error(ais_rc));
+}
+  }
+
+  m_omHandle = 0;
+  m_ownerHandle = 0;
+  m_ccbHandle = 0;
+}
diff --git a/osaf/services/saf/smfsv/smfd/SmfExecControlHdl.h 
b/osaf/services/saf/smfsv/smfd/SmfExecControlHdl.h
--- a/osaf/services/saf/smfsv/smfd/SmfExecControlHdl.h
+++ b/osaf/services/saf/smfsv/smfd/SmfExecControlHdl.h
@@ -85,7 +85,8 @@ class SmfExecControlObjHandler {
   bool readOpenSafSmfConfig();
   bool copyExecControlObject();
   void removeExecControlObjectCopy();
-  bool createAllImmHandles();
+  bool createImmOmHandles();
+  void finalizeImmOmHandles();
   void saveAttributeDescriptors();
 
 
@@ -104,7 +105,7 @@ class SmfExecControlObjHandler {
 
   
   // For OpenSafSmfExecControl object copy
-  const char* c_openSafSmfExecControl_copy = "openSafSmfExecControl_copy";
+  const char* c_openSafSmfExecControl_copy = 
"openSafSmfExecControl=SmfHdlCopy";
   SaImmAttrValuesT_2 **m_attributes;
   SaImmAttrValuesT_2 *m_exec_ctrl_name_ad;
   SaImmAttrValuesT_2 

[devel] [PATCH 0 of 1] Review Request for smf: balanced upgrade, missing removal of exectrl copy [#2114]

[Rafael Odzakow]

Summary: smf: balanced upgrade, missing removal of exectrl copy
Review request for Trac Ticket(s): #2114
Peer Reviewer(s): lennart
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 ae5e92b72a913374d4ce4fd0795ade2724a8a483
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Wed, 12 Oct 2016 13:03:30 +0200

smf: balanced upgrade, missing removal of exectrl copy [#2114]

When doing several bisu upgrades it was noticed that a IMM copy of 
execControl
object was not removed after a upgrade. Looking into the code there is 
a bug
which would case SMF to never remove this execControl copy.


Complete diffstat:
--
 osaf/services/saf/smfsv/smfd/SmfExecControlHdl.cc  |  69 
-
 osaf/services/saf/smfsv/smfd/SmfExecControlHdl.h   |  13 ++---
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc |   1 +
 3 files changed, 51 insertions(+), 32 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.


--
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: handle failed si-swap of middleware [#1605]

[Rafael Odzakow]

ACK


On 10/10/2016 01:46 PM, Neelakanta Reddy wrote:
> Hi Alex,
>
> Reviewed and tested the patch.
> Ack.
>
> /Neel.
>
> On 2016/10/07 11:10 PM, Alex Jones wrote:
>> osaf/services/saf/smfsv/smfd/SmfStepState.cc|  13 
>>   osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |  68 
>> +---
>>   osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh |   6 +
>>   3 files changed, 76 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/SmfStepState.cc 
>> b/osaf/services/saf/smfsv/smfd/SmfStepState.cc
>> --- a/osaf/services/saf/smfsv/smfd/SmfStepState.cc
>> +++ b/osaf/services/saf/smfsv/smfd/SmfStepState.cc
>> @@ -424,6 +424,19 @@ SmfStepStateUndone::execute(SmfUpgradeSt
>>   {
>>   TRACE_ENTER();
>>   +if (i_step->calculateStepType() != SA_AIS_OK) {
>> +LOG_ER("SmfStepStateUndone: Failed to calculate step 
>> type");
>> +changeState(i_step, SmfStepStateFailed::instance());
>> +TRACE_LEAVE();
>> +return SMF_STEP_FAILED;
>> +}
>> +
>> +if (i_step->getSwitchOver() == true) {
>> +TRACE("Switch over is needed in this step");
>> +TRACE_LEAVE();
>> +return SMF_STEP_SWITCHOVER;
>> +}
>> +
>>   i_step->setRetryCount(0); /* Reset the retry counter */
>>   changeState(i_step, SmfStepStateExecuting::instance());
>>   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,17 @@ 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 {
>> +

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

[Rafael Odzakow]

ACK


On 09/29/2016 02:45 PM, Lennart Lund wrote:
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc |  93 
> ++---
>   osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh |   3 +-
>   2 files changed, 67 insertions(+), 29 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
> @@ -2823,7 +2823,7 @@ SmfAdminOperation::SmfAdminOperation(std
>   // and an immediate return is done
>   // The public methods shall return fail if m_creation_fail is true
>   
> - bool rc = getAllImmHandles();
> + bool rc = initAllImmHandles();
>   if (rc == false) {
>   LOG_NO("%s: getAllImmHandles Fail", __FUNCTION__);
>   m_creation_fail = true;
> @@ -2860,11 +2860,7 @@ SmfAdminOperation::SmfAdminOperation(std
>   
>   SmfAdminOperation::~SmfAdminOperation()
>   {
> - // This frees all IMM handles that's based on the omHandle and
> - // give up admin ownership of Amf Cluster object
> - if (m_omHandle != 0) {
> - (void)immutil_saImmOmFinalize(m_omHandle);
> - }
> +finalizeAllImmHandles();
>   }
>   
>   ///
> @@ -3079,7 +3075,7 @@ bool SmfAdminOperation::restart()
>   /// Get all needed IMM handles. Updates corresponding member variables
>   /// Return false if fail
>   ///
> -bool SmfAdminOperation::getAllImmHandles()
> +bool SmfAdminOperation::initAllImmHandles()
>   {
>   SaAisErrorT ais_rc = SA_AIS_ERR_TRY_AGAIN;
>   int timeout_try_cnt = 6;
> @@ -3156,6 +3152,15 @@ bool SmfAdminOperation::getAllImmHandles
>   return rc;
>   }
>   
> +// Free all IMM handles that's based on the omHandle and
> +// give up admin ownership of Amf Cluster object
> +void SmfAdminOperation::finalizeAllImmHandles() {
> + if (m_omHandle != 0) {
> + (void)immutil_saImmOmFinalize(m_omHandle);
> + }
> +
> +}
> +
>   /// Check if the AIS return is considered a campaign error
>   /// Do not Fail if any of the following AIS codes
>   ///
> @@ -3552,6 +3557,8 @@ bool SmfAdminOperation::createNodeGroup(
>   // 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",
> @@ -3591,8 +3598,7 @@ bool SmfAdminOperation::createNodeGroup(
>   ///
>   bool SmfAdminOperation::deleteNodeGroup()
>   {
> - bool rc = true;
> - m_errno = SA_AIS_OK;
> + SaAisErrorT ais_rc = SA_AIS_OK;
>   
>   TRACE_ENTER();
>   std::string nodeGroupName_s =
> @@ -3602,25 +3608,53 @@ 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;
> - }
> - }
> -
> - TRACE_LEAVE();
> - return rc;
> + bool method_rc = false;
> +const uint32_t MAX_NO_RETRIES = 2;
> +uint32_t retry_cnt = 0;
> +while (++retry_cnt <= MAX_NO_RETRIES) {
> +// Handles including ccb handle may have been invalidated by
> +// IMM resulting in SA_AIS_ERR_BAD_HANDLE response on the
> +// delete object request.
> +// If that's the case: Try to create new handles and try 
> again
> +ais_rc = immutil_saImmOmCcbObjectDelete(m_ccbHandle,
> +);
> +TRACE("%s: immutil_saImmOmCcbObjectDelete %s",
> +__FUNCTION__, saf_error(m_errno));
> +
> +if (ais_rc == SA_AIS_ERR_BAD_HANDLE) {
> +LOG_NO("%s: saImmOmCcbObjectDelete Fail %s",
> +   __FUNCTION__, saf_error(m_errno));
> +finalizeAllImmHandles();
> +bool rc = initAllImmHandles();
> +if 

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

[Rafael Odzakow]

ACK


On 09/29/2016 02:41 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 0 of 1] Review Request for smf:retry of Admin operation for TIMEOUT in si-swap to be avoided [#2069]

[Rafael Odzakow]

ACK


On 09/28/2016 08:49 AM, reddy.neelaka...@oracle.com wrote:
> Summary: smf:retry of Admin operation for TIMEOUT in si-swap to be avoided 
> [#2069]
> Review request for Trac Ticket(s): 2069
> Peer Reviewer(s): Lennart, Rafel
> 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 a2bf2350146e8ad02496a5df5157466dd025760d
> Author:   Neelakanta Reddy
> Date: Wed, 28 Sep 2016 12:15:34 +0530
>
>   smf:retry of Admin operation for TIMEOUT in si-swap to be avoided 
> [#2069]
>
>   For the si-swap operation if TIMEOUT occurs the and the node is active 
> the
>   campaign will fail. If the node is standby SmfCampaignThread::instance()
>   will be terminated at Quiesced state, and nothing will be done.
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |  11 ++-
>   1 files changed, 6 insertions(+), 5 deletions(-)
>
>
> Testing Commands:
> -
> when the camapign is ongoing, simulate a TIMEOUT for si-swap admin operation
>
> Testing, Expected Results:
> --
> with this patch, retry of si-swap is not supported.
>
> Conditions of Submission:
> -
> Ack from Reviewers
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  y  y
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

Re: [devel] [PATCH 0 of 1] Review Request for smf: Avoid flooding of syslog when the upgrade involves node reboot [#2058]

[Rafael Odzakow]

ACK


On 09/29/2016 10:47 AM, reddy.neelaka...@oracle.com wrote:
> Summary: smf: Avoid flooding of syslog when the upgrade involves node reboot 
> [#2058]
> Review request for Trac Ticket(s): 2058
> Peer Reviewer(s): Rafel, Leenart
> 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 servicesn
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>
> changeset 8f7d6e822b28030929e1d6e906b603b5ccd1b758
> Author:   Neelakanta Reddy
> Date: Thu, 29 Sep 2016 14:13:48 +0530
>
>   smf: Avoid flooding of syslog when the upgrade involves node reboot 
> [#2058]
>   If the upgrade involves node reboot, and the rebooted node joins late, 
> then
>   the sylog will be flodded with NO messages
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfUtils.cc |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> Testing Commands:
> -
>
>
> Testing, Expected Results:
> --
> If node, joints late after restart at the time of upgrade, then syslog should 
> not be flooded with messages.
>
> Conditions of Submission:
> -
> Ack from Reviewers
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  y  y
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

[devel] [PATCH 1 of 1] smf: balanced upgrade software bundle missmatch [#2080]

[Rafael Odzakow]

 osaf/services/saf/smfsv/smfd/SmfExecControl.cc |  9 +++--
 1 files changed, 3 insertions(+), 6 deletions(-)


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.

diff --git a/osaf/services/saf/smfsv/smfd/SmfExecControl.cc 
b/osaf/services/saf/smfsv/smfd/SmfExecControl.cc
--- a/osaf/services/saf/smfsv/smfd/SmfExecControl.cc
+++ b/osaf/services/saf/smfsv/smfd/SmfExecControl.cc
@@ -103,13 +103,10 @@ bool createStepForBalancedProc(SmfUpgrad
   SmfCampaign* camp = SmfCampaignThread::instance()->campaign();
   SmfUpgradeCampaign* ucamp = camp->getUpgradeCampaign();
 
-  std::vector steps;
-  for (auto step : getStepsMatchingBalancedGroup(procedure, ucamp)) {
-// copy steps and callbacks
+  auto steps = getStepsMatchingBalancedGroup(procedure, ucamp);
+  for (auto step : steps) {
 SmfUpgradeProcedure* oproc = step->getProcedure();
-steps.insert(steps.end(),
- oproc->getProcSteps().begin(),
- oproc->getProcSteps().end());
+// copy callbacks to the new procedure
 procedure->getCallbackList(oproc->getUpgradeMethod());
   }
   if (!steps.empty()) {

--
___
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:retry for TIMEOUT in si-swap to be avoided [#2069]

[Rafael Odzakow]

ACK


On 09/27/2016 09:20 AM, reddy.neelaka...@oracle.com wrote:
> Summary: smf:retry for TIMEOUT in si-swap to be avoided [#2069]
> Review request for Trac Ticket(s): 2069
> Peer Reviewer(s): Lennart, Rafel
> 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 servicesn
>   OpenSAF servicesy
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>
> changeset 9b4f8af155d0b863cbac45733baa5bdf6fc12ff8
> Author:   Neelakanta Reddy
> Date: Tue, 27 Sep 2016 12:46:13 +0530
>
>   smf:retry for TIMEOUT in si-swap to be avoided [#2069]
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |  4 +---
>   1 files changed, 1 insertions(+), 3 deletions(-)
>
>
> Testing Commands:
> -
> if an si-swap adminoperation of SMF returns TIMEOUT, then re-try of si-swap 
> has been removed.
>
> Testing, Expected Results:
> --
> with this patch, retry of sis-wap has been removed.
>
> Conditions of Submission:
> -
> Ack from reviewers
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  y  y
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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

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

[Rafael Odzakow]

ACK, with comments


On 09/23/2016 10:55 AM, Lennart Lund wrote:
> My own review comments:
>
> See [Lennart] inline
>
> /Lennart
>
>> -Original Message-
>> From: Lennart Lund [mailto:lennart.l...@ericsson.com]
>> Sent: den 22 september 2016 17:04
>> To: Rafael Odzakow <rafael.odza...@ericsson.com>;
>> reddy.neelaka...@oracle.com
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: [devel] [PATCH 1 of 1] smf: Delete node group if already exist when
>> creating [#2049]
>>
>>   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) {
[rafael] suggestion is to not use while loop, instead call ObjectCreate 
twice
>> +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();
> [Lennart] Incorrect scope of rc
>
>> +if (rc == false) {
>> +LOG_NO("%s: deleteNodeGroup() Fail",
>> +   __FUNCTION__);
>> +break;
>> +}
>> +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


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

[Rafael Odzakow]

ACK with previous comments


On 09/23/2016 10:48 AM, Lennart Lund wrote:
> My own comments:
>
> 1)
> Do not set m_errno in object delete method. Not used, not needed. Instead use 
> internal ais_rc where needed
>
> See also [Lennart] inline
>
> /Lennart
>
>> -Original Message-
>> From: Lennart Lund [mailto:lennart.l...@ericsson.com]
>> Sent: den 22 september 2016 15:34
>> To: Rafael Odzakow <rafael.odza...@ericsson.com>;
>> reddy.neelaka...@oracle.com
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: [devel] [PATCH 1 of 1] smf: Recreate IMM handles if bad handle
>> when deleting node group [#2046]
>>
>>   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;
>> -}
>> -}
>> +while (true) {
>> +m_errno = immutil_saImmOmCcbObjectDelete(m_ccbHandle,
>> +);
>> +if (m_errno == SA_AIS_ERR_BAD_HANDLE) {
>> +// Handles may have been invalidated/timed out
>> +(void)immutil_saImmOmFinalize(m_omHandle);
>> +bool rc = getAllImmHandles();
> [Lennart] Incorrect. Is mixed up with merthod return code. Separate method 
> return code and this internal return code. Set method return code if 
> getAllImmHandles() fail.
>
>> +if (rc == false) {
>> +LOG_NO("%s: getAllImmHandles Fail",
>> +   __FUNCTION__);
>> +break;
>> +}
>> +continue;
>> +}
>> +if (m_errno != SA_AIS_OK) {
>> +  LOG_NO("%s: saImmOmCcbObjectDelete '%s' Fail %s",
>> +  __FUNCTION__, nodeGroupName_s.c_str(),
>> +  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;
>> +}
>> +}
>>
>>  TRACE_LEAVE();
>>  return rc;
>> @@ -3633,6 +3647,9 @@ bool SmfAdminOperation::nodeGroupAdminOp
>>  , 0, adminOp, params,
>>  _rc, smfd_cb->adminOpTimeout);
>>
>> +if (m_errno == SA_AIS_OK && oi_rc == SA_AIS_OK)
>> +break;
>> +
>>  if (retry <= 0) {
>>  LOG_NO("Fail to invoke admin operation, too many
>> OI "
>>  "TRY_AGAIN, giving up. %s",
>> __FUNCTION__);
>>
>> --
>> ___
>> Opensaf-devel mailing list
>> Opensaf-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel


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

[Rafael Odzakow]

comments one comment under [rafael] tag.


On 09/22/2016 03:33 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;
> - }
> - }
> +while (true) {
[rafael]  The while loop is here to retry CcbObjectDelete only one time. 
A much clearer way is to call CcbObjectDelete twice. As it looks now I 
needed to reread this section before I understood the logic. By trying 
to avoid writing extra code you have complicated a simple function. Call 
it twice instead of having a while loop that will retry after BAD_HANDLE 
endless amounts of times. A possibility for an infinite loop is not a 
good idea. After the second CcbObjectDelete you can fail normally. 
Please explain in comments or remove this while loop.
> +m_errno = immutil_saImmOmCcbObjectDelete(m_ccbHandle,
> +);
> +if (m_errno == SA_AIS_ERR_BAD_HANDLE) {
> +// Handles may have been invalidated/timed out
> +(void)immutil_saImmOmFinalize(m_omHandle);
> +bool rc = getAllImmHandles();
> +if (rc == false) {
> +LOG_NO("%s: getAllImmHandles Fail",
> +   __FUNCTION__);
> +break;
> +}
> +continue;
> +}
> +if (m_errno != SA_AIS_OK) {
> +  LOG_NO("%s: saImmOmCcbObjectDelete '%s' Fail %s",
> +  __FUNCTION__, nodeGroupName_s.c_str(),
> +  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;
> +}
> +}
>   
>   TRACE_LEAVE();
>   return rc;
> @@ -3633,6 +3647,9 @@ bool SmfAdminOperation::nodeGroupAdminOp
>   , 0, adminOp, params,
>   _rc, smfd_cb->adminOpTimeout);
>   
> +if (m_errno == SA_AIS_OK && oi_rc == SA_AIS_OK)
> +break;
> +
>   if (retry <= 0) {
>   LOG_NO("Fail to invoke admin operation, too many OI "
>   "TRY_AGAIN, giving up. %s", __FUNCTION__);


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

[devel] Review request for updates to SMF PR for 5.1

[Rafael Odzakow]

document for review is attached to ticket #2017

https://sourceforge.net/p/opensaf/tickets/2017/


--
___
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: SMF does not handle AMF long DN support [#1968]

[Rafael Odzakow]

ACK


On 08/29/2016 09:39 AM, Lennart Lund wrote:
> Summary: smf: SMF does not handle AMF long DN support
> Review request for Trac Ticket(s): #1968
> Peer Reviewer(s): rafael.odza...@ericsson.com, reddy.neelaka...@oracle.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 b8b30362ca68218e126f8e48fa916b9feeb90f60
> Author:   Lennart Lund 
> Date: Mon, 29 Aug 2016 09:05:48 +0200
>
>   smf: SMF does not handle AMF long DN support [#1968]
>
>   Allow all IMM objects to have long DN
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/SmfCampaignXmlParser.cc |  36 
> +---
>   osaf/services/saf/smfsv/smfd/SmfUtils.cc |  29 
> -
>   osaf/services/saf/smfsv/smfd/smfd.h  |   1 -
>   osaf/services/saf/smfsv/smfd/smfd_cb.h   |   1 +
>   osaf/services/saf/smfsv/smfd/smfd_main.c |   2 ++
>   osaf/services/saf/smfsv/smfnd/smfnd_main.c   |   3 +++
>   6 files changed, 51 insertions(+), 21 deletions(-)
>
>
> Testing Commands:
> -
> Execute a campaign with long DNs for AMF objects
> Example for a long_dn_campaign.xml:
> safSmfCampaign="safSmfCampaign=ThisIsA300CharLongRDNaaa.
>  safSmfProcedure="safSmfProc=LongDnTestNodeSCThisIsA300CharLongRDN...
>
>
> Testing, Expected Results:
> --
> Campaign shall be completed with no fail
> Example:
> # smf-state camp
> safSmfCampaign=LennartLock,safApp=safSmfService
>  state=EXECUTION_COMPLETED(5)
>  error=''
> #
>
>
> Conditions of Submission:
> -
> Ack from reviewers.
> Also more testing with long DN AMF objects
>
>
> 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 

[devel] [PATCH 2 of 3] fix segfault

[Rafael Odzakow]

 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc |  15 ---
 1 files changed, 4 insertions(+), 11 deletions(-)


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
@@ -84,17 +84,10 @@ class SmfUpgradeProcedure;
 SmfUpgradeCampaign::~SmfUpgradeCampaign()
 {
 TRACE_ENTER();
-//Delete merged procedure first since it contain references to other 
proc
-   //Check campaign state, if verify fails the campaign is still in state 
initial
-   //and the merged procedure is not yet created.
-int procexec = getProcExecutionMode();
-if ((procexec == SMF_MERGE_TO_SINGLE_STEP || procexec == 
SMF_BALANCED_MODE) &&
-   (m_state->getState() != SA_SMF_CMPG_INITIAL)) {
-for (auto& it: m_procedure) {
-delete it;
-}
-m_procedure.clear();
-} 
+for (auto& it: m_procedure) {
+delete it;
+}
+m_procedure.clear();
 for (auto& it: m_originalProcedures) {
 delete it;
 }

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

[devel] [PATCH 1 of 3] smfd: Merge rolling to singlestep procedures for several nodes [#1685]

[Rafael Odzakow]

 osaf/services/saf/smfsv/config/smfsv_classes.xml|  1084 +-
 osaf/services/saf/smfsv/smfd/Makefile.am| 8 +-
 osaf/services/saf/smfsv/smfd/SmfCampState.cc|   151 +--
 osaf/services/saf/smfsv/smfd/SmfCampaign.cc |77 +-
 osaf/services/saf/smfsv/smfd/SmfCampaign.hh | 1 +
 osaf/services/saf/smfsv/smfd/SmfExecControl.cc  |   363 ++
 osaf/services/saf/smfsv/smfd/SmfExecControl.h   |59 +
 osaf/services/saf/smfsv/smfd/SmfExecControlHdl.cc   |   506 
 osaf/services/saf/smfsv/smfd/SmfExecControlHdl.h|   126 ++
 osaf/services/saf/smfsv/smfd/SmfProcState.cc|28 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc  |39 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.hh  |35 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |27 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh |18 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc  |49 +
 osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh  |13 +-
 osaf/services/saf/smfsv/smfd/smfd.h | 2 +-
 osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc|32 -
 osaf/services/saf/smfsv/smfd/smfd_cb.h  | 5 -
 19 files changed, 1842 insertions(+), 781 deletions(-)


diff --git a/osaf/services/saf/smfsv/config/smfsv_classes.xml 
b/osaf/services/saf/smfsv/config/smfsv_classes.xml
--- a/osaf/services/saf/smfsv/config/smfsv_classes.xml
+++ b/osaf/services/saf/smfsv/config/smfsv_classes.xml
@@ -1,535 +1,555 @@
 
 http://www.saforum.org/IMMSchema; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; 
xsi:noNamespaceSchemaLocation="SAI-AIS-IMM-XSD-A.02.13.xsd">
-   
-   SA_CONFIG
-   
-   safSmfCampaign
-   SA_STRING_T
-   SA_CONFIG
-   SA_INITIALIZED
-   
-   
-   saSmfCmpgFileUri
-   SA_STRING_T
-   SA_CONFIG
-   SA_WRITABLE
-   
-   
-   saSmfCmpgConfigBase
-   SA_TIME_T
-   SA_RUNTIME
-   SA_PERSISTENT
-   SA_CACHED
-   
-   
-   saSmfCmpgExpectedTime
-   SA_TIME_T
-   SA_RUNTIME
-   SA_PERSISTENT
-   SA_CACHED
-   
-   
-   saSmfCmpgElapsedTime
-   SA_TIME_T
-   SA_RUNTIME
-   SA_PERSISTENT
-   SA_CACHED
-   
-   
-   saSmfCmpgState
-   SA_UINT32_T
-   SA_RUNTIME
-   SA_PERSISTENT
-   SA_CACHED
-   1
-   
-   
-   saSmfCmpgError
-   SA_STRING_T
-   SA_RUNTIME
-   SA_PERSISTENT
-   SA_CACHED
-   SA_MULTI_VALUE
-   
-   
-   
-   SA_RUNTIME
-   
-   safSmfProcedure
-   SA_STRING_T
-   SA_RUNTIME
-   SA_PERSISTENT
-   SA_CACHED
-   
-   
-   saSmfProcExecLevel
-   SA_UINT32_T
-   SA_RUNTIME
-   SA_PERSISTENT
-   SA_CACHED
-   
-   
-   saSmfProcMustKeepSIs
-   SA_NAME_T
-   SA_RUNTIME
-   SA_PERSISTENT
-   SA_CACHED
-   SA_MULTI_VALUE
-   
-   
-   saSmfProcAcceptSIOutage
-   SA_NAME_T
-   SA_RUNTIME
-   SA_PERSISTENT
-   SA_CACHED
-   SA_MULTI_VALUE
-   
-   
-   saSmfProcMaxNumSIsOutage
-   SA_UINT32_T
-   SA_RUNTIME
-   SA_PERSISTENT
-   SA_CACHED
-   
-   
-   saSmfProcUpgrMethod
-   SA_UINT32_T
-   SA_RUNTIME
-   SA_PERSISTENT
-   SA_CACHED
-   
-   
-   saSmfProcDisableSimultanExec
-   SA_UINT32_T
-   SA_RUNTIME
-   SA_PERSISTENT
-   SA_CACHED
-   
-   
-   saSmfProcPeriod
-

[devel] [PATCH 3 of 3] uniqe actions and assert if controller in nodesForSingleStep

[Rafael Odzakow]

 osaf/services/saf/smfsv/smfd/SmfExecControl.cc  |  121 +++
 osaf/services/saf/smfsv/smfd/SmfExecControl.h   |   11 +-
 osaf/services/saf/smfsv/smfd/SmfProcState.cc|5 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |   39 -
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh |2 +
 osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc  |   45 ---
 6 files changed, 84 insertions(+), 139 deletions(-)


diff --git a/osaf/services/saf/smfsv/smfd/SmfExecControl.cc 
b/osaf/services/saf/smfsv/smfd/SmfExecControl.cc
--- a/osaf/services/saf/smfsv/smfd/SmfExecControl.cc
+++ b/osaf/services/saf/smfsv/smfd/SmfExecControl.cc
@@ -29,17 +29,14 @@
 
 namespace execctrl {
 
-static std::vector 
getStepsMatchingBalancedGroup(SmfUpgradeProcedure* procedure);
-
-static void addInitAndWrapupActionsToProcedure(SmfUpgradeProcedure* procedure,
-const std::vector& initactions,
-const std::vector& wrapupactions);
+static std::vector 
getStepsMatchingBalancedGroup(SmfUpgradeProcedure* procedure,
+  
SmfUpgradeCampaign* ucamp);
 
 static SmfUpgradeStep* mergeStep(SmfUpgradeProcedure* procedure,
-const std::vector& steps);
+ const std::vector& steps);
 
 static bool removeDuplicateActivationUnits(SmfUpgradeProcedure * i_newproc,
-SmfUpgradeStep *newStep);
+   SmfUpgradeStep *newStep);
 
 
 static bool isNodeInGroup(const std::string& node,
@@ -50,17 +47,18 @@ static bool isNodeInGroup(const std::str
 bool createBalancedProcs() {
   // Creates new procedures based on the ExecControl configuration
   TRACE_ENTER();
-  auto ucamp = SmfCampaignThread::instance()->campaign()->getUpgradeCampaign();
-  auto exechdl = ucamp->getExecControlHdl();
+  SmfCampaign* camp = SmfCampaignThread::instance()->campaign();
+  SmfUpgradeCampaign* ucamp = camp->getUpgradeCampaign();
+  SmfExecControlObjHandler* exechdl = ucamp->getExecControlHdl();
 
   bool errinfo = false;
-  auto numberofss = exechdl->numberOfSingleSteps();
+  SaUint32T numberofss = exechdl->numberOfSingleSteps();
   if (errinfo == false) {
 TRACE("Failed reading attribute from ExecControlHdl");
 return false;
   }
   // Assume that nodesForSingleStep only contains nodes used by the campaign.
-  auto nodesforss = exechdl->nodesForSingleStep();
+  std::vector nodesforss = exechdl->nodesForSingleStep();
   if (errinfo == false) {
 TRACE("Failed reading attribute from ExecControlHdl");
 return false;
@@ -102,43 +100,47 @@ bool createBalancedProcs() {
 
 bool createStepForBalancedProc(SmfUpgradeProcedure* procedure) {
   TRACE_ENTER();
+  SmfCampaign* camp = SmfCampaignThread::instance()->campaign();
+  SmfUpgradeCampaign* ucamp = camp->getUpgradeCampaign();
+
   std::vector steps;
-  std::vector initactions;
-  std::vector wrapupactions;
-  for (auto step : getStepsMatchingBalancedGroup(procedure)) {
-// copy the steps together with actions and callbacks
-auto oproc = step->getProcedure();
+  for (auto step : getStepsMatchingBalancedGroup(procedure, ucamp)) {
+// copy steps and callbacks
+SmfUpgradeProcedure* oproc = step->getProcedure();
 steps.insert(steps.end(),
  oproc->getProcSteps().begin(),
  oproc->getProcSteps().end());
-initactions.insert(initactions.end(),
-   oproc->getInitActions().begin(),
-   oproc->getInitActions().end());
-wrapupactions.insert(wrapupactions.end(),
- oproc->getWrapupActions().begin(),
- oproc->getWrapupActions().end());
 procedure->getCallbackList(oproc->getUpgradeMethod());
   }
   if (!steps.empty()) {
 SmfUpgradeStep* newstep = mergeStep(procedure, steps);
-addInitAndWrapupActionsToProcedure(procedure, initactions, wrapupactions);
 removeDuplicateActivationUnits(procedure, newstep);
 procedure->addProcStep(newstep);
   }
+  const std::vector& allprocs = ucamp->getProcedures();
+  if (procedure == (*--allprocs.end())) {
+// This is the last balanced procedure configure the wrapup actions.
+for (auto wac : procedure->getWrapupActions()) {
+  const SmfCallbackAction* cba = dynamic_cast(wac);
+  if (cba != nullptr) {
+const_cast(cba)->setCallbackProcedure(procedure);
+  }
+}
+  }
   TRACE_LEAVE();
   return true;
 }
 
-bool allStepsMerged(SmfUpgradeProcedure* procedure) {
+void disableMergeSteps(SmfUpgradeProcedure* procedure) {
   TRACE_ENTER();
   if (!procedure->getBalancedGroup().empty()) {
 TRACE("not an original proc");
-return false;
+return;
   }
-  auto camp = 

[devel] [PATCH 0 of 3] Review Request for Merge rolling to singlestep procedures for several nodes [#1685]

[Rafael Odzakow]

Summary: Merge rolling to singlestep procedures for several nodes
Review request for Trac Ticket(s): #1685
Peer Reviewer(s): lennart
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 3850c8ad75dcb065cb6eddf94f50958fcce63e60
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Mon, 05 Sep 2016 09:47:53 +0200

smfd: Merge rolling to singlestep procedures for several nodes [#1685]

Enables the balanced mode feature. This mode changes the execution
of rolling procedures to be merged into one or several single steps that are
spread out across the cluster nodes. This feature is used to give a faster
upgrade time compared to rolling one node at a time, possibly several times
for each node. By splittting the procedures it into several single steps
across the nodes a total service outage can be avoided.

changeset 9b8d7458afe23b3ad57a7552ac128ea519a57ace
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Fri, 09 Sep 2016 15:27:39 +0200

fix segfault

changeset a3b28459cdcbd62917cbb0d252cbaa086e475324
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Mon, 12 Sep 2016 00:13:06 +0200

uniqe actions and assert if controller in nodesForSingleStep


Added Files:

 osaf/services/saf/smfsv/smfd/SmfExecControl.cc
 osaf/services/saf/smfsv/smfd/SmfExecControl.h
 osaf/services/saf/smfsv/smfd/SmfExecControlHdl.cc
 osaf/services/saf/smfsv/smfd/SmfExecControlHdl.h


Complete diffstat:
--
 osaf/services/saf/smfsv/config/smfsv_classes.xml|  1084 
++---
 osaf/services/saf/smfsv/smfd/Makefile.am| 8 +-
 osaf/services/saf/smfsv/smfd/SmfCampState.cc|   151 

 osaf/services/saf/smfsv/smfd/SmfCampaign.cc |77 +++-
 osaf/services/saf/smfsv/smfd/SmfCampaign.hh | 1 +
 osaf/services/saf/smfsv/smfd/SmfExecControl.cc  |   334 
++
 osaf/services/saf/smfsv/smfd/SmfExecControl.h   |58 +
 osaf/services/saf/smfsv/smfd/SmfExecControlHdl.cc   |   506 
+++
 osaf/services/saf/smfsv/smfd/SmfExecControlHdl.h|   126 

 osaf/services/saf/smfsv/smfd/SmfProcState.cc|25 +++-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc  |40 +++--
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.hh  |35 ++---
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |64 --
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh |20 ++-
 osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc  | 4 +
 osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh  |13 +-
 osaf/services/saf/smfsv/smfd/smfd.h | 2 +-
 osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc|32 -
 osaf/services/saf/smfsv/smfd/smfd_cb.h  | 5 -
 19 files changed, 1792 insertions(+), 793 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 leve

Re: [devel] [PATCH 1 of 1] smfd: Merge rolling to singlestep procedures for several nodes [#1685]

[Rafael Odzakow]

Hello,

2. Yes in this version only PLs are allowed in nodesForSingleStep. We 
should fail more gracefully. An defect ticket will be written to fix 
this issue.


On 09/02/2016 02:11 PM, Neelakanta Reddy wrote:
> Hi Rafel,
>
> Tested the patch, but following are the comments:
>
> 1. when the controllers are included
>
> immcfg -a numberOfSingleSteps=2  -a nodesForSingleStep=SC-1 -a 
> nodesForSingleStep=SC-2  openSafSmfExecControl=MergeCampToSS2
>
> I have seen the segmentation fault.
>
> Sep  2 17:10:03 SLES1 osafsmfd[2551]: ER SmfProcedureThread::init, 
> getImmSteps FAILED, rc=SA_AIS_ERR_NOT_EXIST (12)
> Sep  2 17:10:03 SLES1 osafsmfd[2551]: ER SmfProcedureThread::main, 
> SmfProcedureThread: init failed
> Sep  2 17:10:03 SLES1 osafsmfd[2551]: ER Start of procedure thread 
> failed for 
> safSmfProc=SmfBalancedProc0,safSmfCampaign=Campaign1,safApp=safSmfService
> Sep  2 17:10:03 SLES1 osafimmnd[2459]: NO Implementer disconnected 11 
> <336, 2010f> (safSmfProc1)
> Sep  2 17:10:03 SLES1 osafimmnd[2459]: NO Implementer disconnected 12 
> <411, 2010f> (safSmfProc2)
> Sep  2 17:10:03 SLES1 osafimmnd[2459]: NO Implementer disconnected 15 
> <480, 2010f> (safSmfProc3)
> Sep  2 17:10:03 SLES1 osafamfnd[2520]: NO 
> 'safComp=SMF,safSu=SC-1,safSg=2N,safApp=OpenSAF' faulted due to 
> 'avaDown' : Recovery is 'nodeFailfast'
> Sep  2 17:10:03 SLES1 osafamfnd[2520]: ER 
> safComp=SMF,safSu=SC-1,safSg=2N,safApp=OpenSAF Faulted due to:avaDown 
> Recovery is:nodeFailfast
> Sep  2 17:10:03 SLES1 osafamfnd[2520]: Rebooting OpenSAF NodeId = 
> 131343 EE Name = , Reason: Component faulted: recovery is node 
> failfast, OwnNodeId = 131343, SupervisionTime = 60
> Sep  2 17:10:03 SLES1 kernel: [  163.790156] osafsmfd[2675]: segfault 
> at 51 ip 7f1c89310b08 sp 7f1c8bd968c0 error 4 in 
> libgcc_s.so.1[7f1c89301000+16000]
> Sep  2 17:05:46 SLES1 osafimmnd[2483]: NO Implementer locally 
> disconnected. Marking it as doomed 16 <546, 2010f> (safSmfProc4)
> Sep  2 17:05:46 SLES1 osafimmnd[2483]: NO Implementer locally 
> disconnected. Marking it as doomed 9 <314, 2010f> (safSmfService)
> Sep  2 17:05:46 SLES1 osafimmnd[2483]: NO Implementer locally 
> disconnected. Marking it as doomed 10 <326, 2010f> (safSmfCampaign)
> Sep  2 17:05:46 SLES1 osafimmnd[2483]: NO Implementer disconnected 16 
> <546, 2010f> (safSmfProc4)
> Sep  2 17:05:46 SLES1 osafimmnd[2483]: NO Implementer disconnected 9 
> <314, 2010f> (safSmfService)
> Sep  2 17:05:46 SLES1 opensaf_reboot: Rebooting local node; timeout=60
>
>
> bt(full bt i did not get):
>
> signal: 11 pid: 96 uid: 0
> /usr/lib/../lib64/libopensaf_core.so.0(+0x1dfed)[0x7f69a5b42fed]
> /lib64/libpthread.so.0(+0xf7c0)[0x7f69a481f7c0]
> /usr/lib64/opensaf/osafsmfd[0x429539]
> /usr/lib64/opensaf/osafsmfd[0x42b5dd]
> /usr/lib64/opensaf/osafsmfd[0x410801]
> /usr/lib64/opensaf/osafsmfd[0x410a38]
> /usr/lib64/opensaf/osafsmfd[0x40aae3]
> /usr/lib64/opensaf/osafsmfd(_ZN17SmfCampaignThread4mainEPv+0x32)[0x40abe2] 
>
> /lib64/libpthread.so.0(+0x77b6)[0x7f69a48177b6]
> /lib64/libc.so.6(clone+0x6d)[0x7f69a37bb9cd]
>
> smfd traces:
> Sep  2 17:10:03.789791 osafsmfd [2551:SmfProcedureThread.cc:0060] TR 
> Procedure thread exits
> Sep  2 17:10:03.789799 osafsmfd [2551:SmfProcedureThread.cc:0088] >> 
> ~SmfProcedureThread
> Sep  2 17:10:03.789836 osafsmfd [2551:SmfProcedureThread.cc:0096] << 
> ~SmfProcedureThread
> Sep  2 17:10:03.789872 osafsmfd [2551:SmfProcedureThread.cc:0178] << stop
> Sep  2 17:10:03.789888 osafsmfd [2551:SmfUpgradeProcedure.cc:0159] << 
> ~SmfUpgradeProcedure
> Sep  2 17:10:03.789897 osafsmfd [2551:SmfUpgradeProcedure.cc:0121] >> 
> ~SmfUpgradeProcedure
> Sep  2 17:10:03.789905 osafsmfd [2551:SmfUpgradeProcedure.cc:0159] << 
> ~SmfUpgradeProcedure
> Sep  2 17:10:03.789913 osafsmfd [2551:SmfUpgradeProcedure.cc:0121] >> 
> ~SmfUpgradeProcedure
> Sep  2 17:10:03.789921 osafsmfd [2551:SmfUpgradeProcedure.cc:0159] << 
> ~SmfUpgradeProcedure
> Sep  2 17:10:03.789929 osafsmfd [2551:SmfUpgradeCampaign.cc:0103] << 
> ~SmfUpgradeCampaign
> Sep  2 17:10:03.789959 osafsmfd [2551:SmfUpgradeCampaign.cc:0796] >> 
> execute
>
>
> 2.
> Is this enhancement , considers only PLs for nodesForSingleStep? If 
> yes, then SCs should not be allowed.
> There must be check, to allow only PLs.
>
> Regards,
> Neel.
>
>
>
> On 2016/09/01 02:27 PM, Rafael Odzakow wrote:
>> osaf/services/saf/smfsv/config/smfsv_classes.xml|   13 +
>>   osaf/services/saf/smfsv/smfd/Makefile.am|6 +-
>>   osaf/services/saf/smfsv/smfd/SmfCampState.cc|  126 +-
>>   osaf/services/saf/

[devel] [PATCH 0 of 1] Review Request for smfd: Merge rolling to singlestep procedures for several nodes [#1685]

[Rafael Odzakow]

Summary: Merge rolling to singlestep procedures for several nodes
Review request for Trac Ticket(s): #1685
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 servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-
 Added SI-Swap to this feature. There are two main function calls independent
 of each other when doing si-swap. The class seemed redundant so it got 
refactored
 out. Missing is the protection for openSafSmfExecControl attribute in 
SmfConfig.

changeset 931d77e6c9bc04dc4e55f6264e2fcde4070e8203
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Thu, 01 Sep 2016 10:46:53 +0200

smfd: Merge rolling to singlestep procedures for several nodes [#1685]

Enables the balanced mode feature. This mode changes the execution
of rolling procedures to be merged into one or several single steps that are
spread out across the cluster nodes. This feature is used to give a faster
upgrade time compared to rolling one node at a time, possibly several times
for each node. By splittting the procedures it into several single steps
across the nodes a total service outage can be avoided.


Added Files:

 osaf/services/saf/smfsv/smfd/SmfExecControl.cc
 osaf/services/saf/smfsv/smfd/SmfExecControl.h


Complete diffstat:
--
 osaf/services/saf/smfsv/config/smfsv_classes.xml|   13 +
 osaf/services/saf/smfsv/smfd/Makefile.am|6 +-
 osaf/services/saf/smfsv/smfd/SmfCampState.cc|  126 
+-
 osaf/services/saf/smfsv/smfd/SmfCampaign.cc |   77 
+++-
 osaf/services/saf/smfsv/smfd/SmfCampaign.hh |1 +
 osaf/services/saf/smfsv/smfd/SmfExecControl.cc  |  410 
+++
 osaf/services/saf/smfsv/smfd/SmfExecControl.h   |   59 
+
 osaf/services/saf/smfsv/smfd/SmfProcState.cc|   28 +++-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc  |   32 +
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.hh  |   24 --
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |   27 ---
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh |   18 ++-
 osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh  |   13 ++---
 osaf/services/saf/smfsv/smfd/smfd.h |2 +-
 14 files changed, 653 insertions(+), 183 deletions(-)


Testing Commands:
-
 Campaign with rolling procedures is attached to the ticket. Run a campaign
 with rolling procedures on payloads and enable the balanced mode. Example
 configuration for balanced mode:

 immcfg -c OpenSafSmfExecControl -a procExecMode=2 
openSafSmfExecControl=MergeCampToSS2o
 immcfg -a numberOfSingleSteps=2 -a nodesForSingleStep=PL-3 -a 
nodesForSingleStep=PL-4 openSafSmfExecControl=MergeCampToSS2
 immcfg -a openSafSmfExecControl=openSafSmfExecControl=MergeCampToSS2 
smfConfig=1,safApp=safSmfService

 In this configuration we can expect to run one single step procedures on each 
of the payloads specified

Testing, Expected Results:
--
  campaign should have executed all rolling steps as groups of single steps.

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 test

[devel] [PATCH 1 of 1] smfd: Merge rolling to singlestep procedures for several nodes [#1685]

[Rafael Odzakow]

 osaf/services/saf/smfsv/config/smfsv_classes.xml|   13 +
 osaf/services/saf/smfsv/smfd/Makefile.am|6 +-
 osaf/services/saf/smfsv/smfd/SmfCampState.cc|  126 +-
 osaf/services/saf/smfsv/smfd/SmfCampaign.cc |   77 ++-
 osaf/services/saf/smfsv/smfd/SmfCampaign.hh |1 +
 osaf/services/saf/smfsv/smfd/SmfExecControl.cc  |  410 
 osaf/services/saf/smfsv/smfd/SmfExecControl.h   |   59 ++
 osaf/services/saf/smfsv/smfd/SmfProcState.cc|   28 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc  |   32 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.hh  |   24 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |   27 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh |   18 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh  |   13 +-
 osaf/services/saf/smfsv/smfd/smfd.h |2 +-
 14 files changed, 653 insertions(+), 183 deletions(-)


diff --git a/osaf/services/saf/smfsv/config/smfsv_classes.xml 
b/osaf/services/saf/smfsv/config/smfsv_classes.xml
--- a/osaf/services/saf/smfsv/config/smfsv_classes.xml
+++ b/osaf/services/saf/smfsv/config/smfsv_classes.xml
@@ -531,5 +531,18 @@
SA_WRITABLE
0

+   
+   numberOfSingleSteps
+   SA_UINT32_T
+   SA_CONFIG
+   SA_WRITABLE
+   
+   
+   nodesForSingleStep
+   SA_STRING_T
+   SA_CONFIG
+  SA_WRITABLE
+   SA_MULTI_VALUE
+   

 
diff --git a/osaf/services/saf/smfsv/smfd/Makefile.am 
b/osaf/services/saf/smfsv/smfd/Makefile.am
--- a/osaf/services/saf/smfsv/smfd/Makefile.am
+++ b/osaf/services/saf/smfsv/smfd/Makefile.am
@@ -49,7 +49,8 @@ noinst_HEADERS = \
SmfCampaignWrapup.hh \
SmfCampaignInit.hh \
SmfCallback.hh \
-   SmfCbkUtil.hh
+   SmfCbkUtil.hh \
+   SmfExecControl.h
 
 osafsmfd_CXXFLAGS = $(AM_CXXFLAGS) @XML2_CFLAGS@
 
@@ -87,7 +88,8 @@ osafsmfd_SOURCES = \
SmfCampaignInit.cc \
SmfCampaignWrapup.cc \
SmfCallback.cc \
-   SmfCbkUtil.cc
+   SmfCbkUtil.cc \
+   SmfExecControl.cc
 
 osafsmfd_LDFLAGS = \
$(AM_LDFLAGS) \
diff --git a/osaf/services/saf/smfsv/smfd/SmfCampState.cc 
b/osaf/services/saf/smfsv/smfd/SmfCampState.cc
--- a/osaf/services/saf/smfsv/smfd/SmfCampState.cc
+++ b/osaf/services/saf/smfsv/smfd/SmfCampState.cc
@@ -32,8 +32,10 @@
 #include "SmfCampaignThread.hh"
 #include "SmfCampaign.hh"
 #include "SmfProcedureThread.hh"
+#include "smfsv_defs.h"
 #include 
 #include 
+#include "SmfUpgradeAction.hh"
 /* 
  *   DEFINITIONS
  * 
@@ -764,12 +766,7 @@ SmfCampStateExecuting::execute(SmfUpgrad
//must be restarted. The execution shall continue at step execution 
phase. The procedure initialization
//and step calculation was performed before the move of control.
 
-std::vector < SmfUpgradeProcedure * > procedures;
-if (i_camp->getProcExecutionMode() == SMF_MERGE_TO_SINGLE_STEP) {
-procedures.push_back(i_camp->getMergedProc());
-} else {
-procedures = i_camp->getProcedures();
-}
+std::vector procedures = i_camp->getProcedures();
 
 std::vector < SmfUpgradeProcedure * >::iterator iter;
bool execProcFound = false;
@@ -817,13 +814,7 @@ SmfCampStateExecuting::executeProc(SmfUp
//The procedure vector is sorted in execution level order (low -> high)
//Lowest number shall be executed first.
 
-std::vector < SmfUpgradeProcedure * > procedures;
-if (i_camp->getProcExecutionMode() == SMF_MERGE_TO_SINGLE_STEP) {
-procedures.push_back(i_camp->getMergedProc());
-} else {
-procedures = i_camp->getProcedures();
-}
-
+std::vector procedures = i_camp->getProcedures();
std::vector < SmfUpgradeProcedure * >::iterator iter;
int execLevel = -1;
 
@@ -912,12 +903,7 @@ SmfCampStateExecuting::suspend(SmfUpgrad
TRACE("SmfCampStateExecuting::suspend implementation");
 
/* Send suspend message to all procedures */
-std::vector < SmfUpgradeProcedure * > procedures;
-if (i_camp->getProcExecutionMode() == SMF_MERGE_TO_SINGLE_STEP) {
-procedures.push_back(i_camp->getMergedProc());
-} else {
-procedures = i_camp->getProcedures();
-}
+std::vector procedures = i_camp->getProcedures();
 
std::vector < SmfUpgradeProcedure * >::iterator iter;
 
@@ -966,12 +952,7 @@ SmfCampStateExecuting::procResult(SmfUpg
 

[devel] [PATCH 0 of 1] Review Request for smfd: Merge rolling to singlestep procedures for several nodes [#1685]

[Rafael Odzakow]

Summary: smfd: Merge rolling to singlestep procedures for several nodes
Review request for Trac Ticket(s): #1685
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 servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-
 Missing the si-swap implementation and OI for some extra checks.

changeset a383f0ebdb5602d9799ee69f3bdf59e479413fb9
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Tue, 23 Aug 2016 10:02:51 +0200

smfd: Merge rolling to singlestep procedures for several nodes [#1685]

Enables the balanced mode feature. This mode changes the execution
of rolling procedures to be merged into one or several single steps that are
spread out across the cluster nodes. This feature is used to give a faster
upgrade time compared to rolling one node at a time, possibly several times
for each node. By splittting the procedures it into several single steps
across the nodes a total service outage can be avoided.

Added Files:

 osaf/services/saf/smfsv/smfd/SmfExecControl.cc
 osaf/services/saf/smfsv/smfd/SmfExecControl.h


Complete diffstat:
--
 osaf/services/saf/smfsv/config/smfsv_classes.xml|   13 +
 osaf/services/saf/smfsv/smfd/Makefile.am|6 +-
 osaf/services/saf/smfsv/smfd/SmfCampState.cc|  126 
--
 osaf/services/saf/smfsv/smfd/SmfCampaign.cc |   78 
++
 osaf/services/saf/smfsv/smfd/SmfCampaign.hh |1 +
 osaf/services/saf/smfsv/smfd/SmfExecControl.cc  |  423 
+++
 osaf/services/saf/smfsv/smfd/SmfExecControl.h   |   64 
+
 osaf/services/saf/smfsv/smfd/SmfProcState.cc|7 ++-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc  |   32 +++-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.hh  |   24 -
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |   14 +++--
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh |   20 ++-
 osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh  |   13 ++--
 osaf/services/saf/smfsv/smfd/smfd.h |2 +-
 14 files changed, 638 insertions(+), 185 deletions(-)


Testing Commands:
-
 Campaign with rolling procedures is attached to the ticket. Run a campaign
 with rolling procedures on payloads and enable the balanced mode. Example
 configuration for balanced mode:

 immcfg -c OpenSafSmfExecControl -a procExecMode=2 
openSafSmfExecControl=MergeCampToSS2o
 immcfg -a numberOfSingleSteps=2 -a nodesForSingleStep=PL-3 -a 
nodesForSingleStep=PL-4 openSafSmfExecControl=MergeCampToSS2
 immcfg -a openSafSmfExecControl=openSafSmfExecControl=MergeCampToSS2 
smfConfig=1,safApp=safSmfService

 In this configuration we can expect to run one single step procedures on each 
of the payloads specified


Testing, Expected Results:
--
 campaign should have executed all steps.


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 spac

[devel] [PATCH 1 of 1] smfd: Merge rolling to singlestep procedures for several nodes [#1685]

[Rafael Odzakow]

 osaf/services/saf/smfsv/config/smfsv_classes.xml|   13 +
 osaf/services/saf/smfsv/smfd/Makefile.am|6 +-
 osaf/services/saf/smfsv/smfd/SmfCampState.cc|  126 +
 osaf/services/saf/smfsv/smfd/SmfCampaign.cc |   78 ++-
 osaf/services/saf/smfsv/smfd/SmfCampaign.hh |1 +
 osaf/services/saf/smfsv/smfd/SmfExecControl.cc  |  423 
 osaf/services/saf/smfsv/smfd/SmfExecControl.h   |   64 +++
 osaf/services/saf/smfsv/smfd/SmfProcState.cc|7 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc  |   32 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.hh  |   24 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |   14 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh |   20 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh  |   13 +-
 osaf/services/saf/smfsv/smfd/smfd.h |2 +-
 14 files changed, 638 insertions(+), 185 deletions(-)


diff --git a/osaf/services/saf/smfsv/config/smfsv_classes.xml 
b/osaf/services/saf/smfsv/config/smfsv_classes.xml
--- a/osaf/services/saf/smfsv/config/smfsv_classes.xml
+++ b/osaf/services/saf/smfsv/config/smfsv_classes.xml
@@ -531,5 +531,18 @@
SA_WRITABLE
0

+   
+   numberOfSingleSteps
+   SA_UINT32_T
+   SA_CONFIG
+   SA_WRITABLE
+   
+   
+   nodesForSingleStep
+   SA_STRING_T
+   SA_CONFIG
+  SA_WRITABLE
+   SA_MULTI_VALUE
+   

 
diff --git a/osaf/services/saf/smfsv/smfd/Makefile.am 
b/osaf/services/saf/smfsv/smfd/Makefile.am
--- a/osaf/services/saf/smfsv/smfd/Makefile.am
+++ b/osaf/services/saf/smfsv/smfd/Makefile.am
@@ -49,7 +49,8 @@ noinst_HEADERS = \
SmfCampaignWrapup.hh \
SmfCampaignInit.hh \
SmfCallback.hh \
-   SmfCbkUtil.hh
+   SmfCbkUtil.hh \
+   SmfExecControl.h
 
 osafsmfd_CXXFLAGS = $(AM_CXXFLAGS) @XML2_CFLAGS@
 
@@ -87,7 +88,8 @@ osafsmfd_SOURCES = \
SmfCampaignInit.cc \
SmfCampaignWrapup.cc \
SmfCallback.cc \
-   SmfCbkUtil.cc
+   SmfCbkUtil.cc \
+   SmfExecControl.cc
 
 osafsmfd_LDFLAGS = \
$(AM_LDFLAGS) \
diff --git a/osaf/services/saf/smfsv/smfd/SmfCampState.cc 
b/osaf/services/saf/smfsv/smfd/SmfCampState.cc
--- a/osaf/services/saf/smfsv/smfd/SmfCampState.cc
+++ b/osaf/services/saf/smfsv/smfd/SmfCampState.cc
@@ -32,8 +32,10 @@
 #include "SmfCampaignThread.hh"
 #include "SmfCampaign.hh"
 #include "SmfProcedureThread.hh"
+#include "smfsv_defs.h"
 #include 
 #include 
+#include "SmfUpgradeAction.hh"
 /* 
  *   DEFINITIONS
  * 
@@ -764,12 +766,7 @@ SmfCampStateExecuting::execute(SmfUpgrad
//must be restarted. The execution shall continue at step execution 
phase. The procedure initialization
//and step calculation was performed before the move of control.
 
-std::vector < SmfUpgradeProcedure * > procedures;
-if (i_camp->getProcExecutionMode() == SMF_MERGE_TO_SINGLE_STEP) {
-procedures.push_back(i_camp->getMergedProc());
-} else {
-procedures = i_camp->getProcedures();
-}
+std::vector procedures = i_camp->getProcedures();
 
 std::vector < SmfUpgradeProcedure * >::iterator iter;
bool execProcFound = false;
@@ -817,13 +814,7 @@ SmfCampStateExecuting::executeProc(SmfUp
//The procedure vector is sorted in execution level order (low -> high)
//Lowest number shall be executed first.
 
-std::vector < SmfUpgradeProcedure * > procedures;
-if (i_camp->getProcExecutionMode() == SMF_MERGE_TO_SINGLE_STEP) {
-procedures.push_back(i_camp->getMergedProc());
-} else {
-procedures = i_camp->getProcedures();
-}
-
+std::vector procedures = i_camp->getProcedures();
std::vector < SmfUpgradeProcedure * >::iterator iter;
int execLevel = -1;
 
@@ -912,12 +903,7 @@ SmfCampStateExecuting::suspend(SmfUpgrad
TRACE("SmfCampStateExecuting::suspend implementation");
 
/* Send suspend message to all procedures */
-std::vector < SmfUpgradeProcedure * > procedures;
-if (i_camp->getProcExecutionMode() == SMF_MERGE_TO_SINGLE_STEP) {
-procedures.push_back(i_camp->getMergedProc());
-} else {
-procedures = i_camp->getProcedures();
-}
+std::vector procedures = i_camp->getProcedures();
 
std::vector < SmfUpgradeProcedure * >::iterator iter;
 
@@ -966,12 +952,7 @@ SmfCampStateExecuting::procResult(SmfUpg
 

[devel] [PATCH 0 of 1] Review Request for smfd: Merge rolling to singlestep procedures for several nodes [#1685]

[Rafael Odzakow]

Summary: smfd: Merge rolling to singlestep procedures for several nodes
Review request for Trac Ticket(s): #1685
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 servicesy
 OpenSAF servicesn
 Core libraries  n
 Samples n
 Tests   n
 Other   n


Comments (indicate scope for each "y" above):
-
 Still missing: 
   si-swap handling to be added
   oi for openSafSmfExecControl to be added

changeset 95f9f432c9d79c29a2ba971add5ad490f28ca0a3
Author: Rafael Odzakow <rafael.odza...@ericsson.com>
Date:   Tue, 23 Aug 2016 10:02:51 +0200

smfd: Merge rolling to singlestep procedures for several nodes [#1685]

This commit enables the balanced mode feature. This mode changes the execution
of rolling procedures to be merged into one or several single steps that are
spread out across the cluster nodes. This feature is used to give a faster
upgrade time compared to rolling procedures upgrading one node at a time,
possibly several times for each node. By splittting the procedures it into
several single steps across the nodes a total service outage can be avoided.


Added Files:

 osaf/services/saf/smfsv/smfd/SmfExecControl.cc
 osaf/services/saf/smfsv/smfd/SmfExecControl.h


Complete diffstat:
--
 osaf/services/saf/smfsv/config/smfsv_classes.xml|   13 +
 osaf/services/saf/smfsv/smfd/Makefile.am|6 +-
 osaf/services/saf/smfsv/smfd/SmfCampState.cc|  125 
---
 osaf/services/saf/smfsv/smfd/SmfCampaign.cc |   78 
--
 osaf/services/saf/smfsv/smfd/SmfCampaign.hh |1 +
 osaf/services/saf/smfsv/smfd/SmfExecControl.cc  |  399 
+++
 osaf/services/saf/smfsv/smfd/SmfExecControl.h   |   56 
+
 osaf/services/saf/smfsv/smfd/SmfProcState.cc|7 ++-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc  |   32 --
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.hh  |   24 --
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |   14 --
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh |   20 +++-
 osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh  |   13 ++---
 osaf/services/saf/smfsv/smfd/smfd.h |2 +-
 14 files changed, 605 insertions(+), 185 deletions(-)


Testing Commands:
-
Campaign with rolling procedures is attached to the ticket. Run a campaign with
rolling procedures on payloads and enable the balanced mode:

 immcfg -c OpenSafSmfExecControl -a procExecMode=2 
openSafSmfExecControl=MergeCampToSS2
 immcfg -a numberOfSingleSteps=2 -a nodesForSingleStep=PL-3 -a 
nodesForSingleStep=PL-4 openSafSmfExecControl=MergeCampToSS2
 immcfg -a openSafSmfExecControl=openSafSmfExecControl=MergeCampToSS2 
smfConfig=1,safApp=safSmfService

 In this configuration we can expect to run one single step procedures on each 
of the payloads specified.



Testing, Expected Results:
--
 campaign should have executed all steps according to configuration


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 whites

[devel] [PATCH 1 of 1] smfd: Merge rolling to singlestep procedures for several nodes [#1685]

[Rafael Odzakow]

 osaf/services/saf/smfsv/config/smfsv_classes.xml|   13 +
 osaf/services/saf/smfsv/smfd/Makefile.am|6 +-
 osaf/services/saf/smfsv/smfd/SmfCampState.cc|  125 +-
 osaf/services/saf/smfsv/smfd/SmfCampaign.cc |   78 ++-
 osaf/services/saf/smfsv/smfd/SmfCampaign.hh |1 +
 osaf/services/saf/smfsv/smfd/SmfExecControl.cc  |  399 
 osaf/services/saf/smfsv/smfd/SmfExecControl.h   |   56 ++
 osaf/services/saf/smfsv/smfd/SmfProcState.cc|7 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc  |   32 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.hh  |   24 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc |   14 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh |   20 +-
 osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh  |   13 +-
 osaf/services/saf/smfsv/smfd/smfd.h |2 +-
 14 files changed, 605 insertions(+), 185 deletions(-)


diff --git a/osaf/services/saf/smfsv/config/smfsv_classes.xml 
b/osaf/services/saf/smfsv/config/smfsv_classes.xml
--- a/osaf/services/saf/smfsv/config/smfsv_classes.xml
+++ b/osaf/services/saf/smfsv/config/smfsv_classes.xml
@@ -531,5 +531,18 @@
SA_WRITABLE
0

+   
+   numberOfSingleSteps
+   SA_UINT32_T
+   SA_CONFIG
+   SA_WRITABLE
+   
+   
+   nodesForSingleStep
+   SA_STRING_T
+   SA_CONFIG
+  SA_WRITABLE
+   SA_MULTI_VALUE
+   

 
diff --git a/osaf/services/saf/smfsv/smfd/Makefile.am 
b/osaf/services/saf/smfsv/smfd/Makefile.am
--- a/osaf/services/saf/smfsv/smfd/Makefile.am
+++ b/osaf/services/saf/smfsv/smfd/Makefile.am
@@ -49,7 +49,8 @@ noinst_HEADERS = \
SmfCampaignWrapup.hh \
SmfCampaignInit.hh \
SmfCallback.hh \
-   SmfCbkUtil.hh
+   SmfCbkUtil.hh \
+   SmfExecControl.h
 
 osafsmfd_CXXFLAGS = $(AM_CXXFLAGS) @XML2_CFLAGS@
 
@@ -87,7 +88,8 @@ osafsmfd_SOURCES = \
SmfCampaignInit.cc \
SmfCampaignWrapup.cc \
SmfCallback.cc \
-   SmfCbkUtil.cc
+   SmfCbkUtil.cc \
+   SmfExecControl.cc
 
 osafsmfd_LDFLAGS = \
$(AM_LDFLAGS) \
diff --git a/osaf/services/saf/smfsv/smfd/SmfCampState.cc 
b/osaf/services/saf/smfsv/smfd/SmfCampState.cc
--- a/osaf/services/saf/smfsv/smfd/SmfCampState.cc
+++ b/osaf/services/saf/smfsv/smfd/SmfCampState.cc
@@ -32,6 +32,7 @@
 #include "SmfCampaignThread.hh"
 #include "SmfCampaign.hh"
 #include "SmfProcedureThread.hh"
+#include "smfsv_defs.h"
 #include 
 #include 
 /* 
@@ -764,12 +765,7 @@ SmfCampStateExecuting::execute(SmfUpgrad
//must be restarted. The execution shall continue at step execution 
phase. The procedure initialization
//and step calculation was performed before the move of control.
 
-std::vector < SmfUpgradeProcedure * > procedures;
-if (i_camp->getProcExecutionMode() == SMF_MERGE_TO_SINGLE_STEP) {
-procedures.push_back(i_camp->getMergedProc());
-} else {
-procedures = i_camp->getProcedures();
-}
+std::vector procedures = i_camp->getProcedures();
 
 std::vector < SmfUpgradeProcedure * >::iterator iter;
bool execProcFound = false;
@@ -817,13 +813,7 @@ SmfCampStateExecuting::executeProc(SmfUp
//The procedure vector is sorted in execution level order (low -> high)
//Lowest number shall be executed first.
 
-std::vector < SmfUpgradeProcedure * > procedures;
-if (i_camp->getProcExecutionMode() == SMF_MERGE_TO_SINGLE_STEP) {
-procedures.push_back(i_camp->getMergedProc());
-} else {
-procedures = i_camp->getProcedures();
-}
-
+std::vector procedures = i_camp->getProcedures();
std::vector < SmfUpgradeProcedure * >::iterator iter;
int execLevel = -1;
 
@@ -912,12 +902,7 @@ SmfCampStateExecuting::suspend(SmfUpgrad
TRACE("SmfCampStateExecuting::suspend implementation");
 
/* Send suspend message to all procedures */
-std::vector < SmfUpgradeProcedure * > procedures;
-if (i_camp->getProcExecutionMode() == SMF_MERGE_TO_SINGLE_STEP) {
-procedures.push_back(i_camp->getMergedProc());
-} else {
-procedures = i_camp->getProcedures();
-}
+std::vector procedures = i_camp->getProcedures();
 
std::vector < SmfUpgradeProcedure * >::iterator iter;
 
@@ -966,12 +951,7 @@ SmfCampStateExecuting::procResult(SmfUpg
 LOG_NO("CAMP: Procedure %s returned STEPUNDONE", 
i_procedure->getProcName().c_str());
 
 /* Send suspend message to 

Re: [devel] [PATCH 0 of 1] Review Request for smfd:check smfNodeBundleActCmd at the time of modification [#1903]

[Rafael Odzakow]

ACK

On 06/30/2016 12:47 PM, reddy.neelaka...@oracle.com wrote:
> Summary:smfd:check smfNodeBundleActCmd at the time of modification [#1903]
> Review request for Trac Ticket(s): 1903
> Peer Reviewer(s): Lennart, Rafael
> Affected branch(es): 4.7.x, 5.0.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 98c54fa4b5f4fe15362a4ef92f18ffe6bb25bb8e
> Author:   Neelakanta Reddy
> Date: Thu, 30 Jun 2016 16:13:10 +0530
>
>   smfd:check smfNodeBundleActCmd at the time of modification
>
>   smfd will crash when smfNodeBundleActCmd is set to NULL, because of 
> strdup.
>
>
> Complete diffstat:
> --
>   osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc |  3 +++
>   1 files changed, 3 insertions(+), 0 deletions(-)
>
>
> Testing Commands:
> -
> As explained in the description of the ticket
>
> Testing, Expected Results:
> --
> with this patch smfd should not crash
>
> Conditions of Submission:
> -
> Ack from Reviewers
>
> Arch  Built StartedLinux distro
> ---
> mipsn  n
> mips64  n  n
> x86 n  n
> x86_64  y  y
> powerpc n  n
> powerpc64   n  n
>
>
> Reviewer Checklist:
> ---
> [Submitters: make sure that your review doesn't trigger any checkmarks!]
>
>
> Your checkin has not passed review because (see checked entries):
>
> ___ Your RR template is generally incomplete; it has too many blank entries
>  that need proper data filled in.
>
> ___ You have failed to nominate the proper persons for review and push.
>
> ___ Your patches do not have proper short+long header
>
> ___ You have grammar/spelling in your header that is unacceptable.
>
> ___ You have exceeded a sensible line length in your headers/comments/text.
>
> ___ You have failed to put in a proper Trac Ticket # into your commits.
>
> ___ You have incorrectly put/left internal data in your comments/files
>  (i.e. internal bug tracking tool IDs, product names etc)
>
> ___ You have not given any evidence of testing beyond basic build tests.
>  Demonstrate some level of runtime or other sanity testing.
>
> ___ You have ^M present in some of your files. These have to be removed.
>
> ___ You have needlessly changed whitespace or added whitespace crimes
>  like trailing spaces, or spaces before tabs.
>
> ___ You have mixed real technical changes with whitespace and other
>  cosmetic code cleanup changes. These have to be separate commits.
>
> ___ You need to refactor your submission into logical chunks; there is
>  too much content into a single commit.
>
> ___ You have extraneous garbage in your review (merge commits etc)
>
> ___ You have giant attachments which should never have been sent;
>  Instead you should place your content in a public tree to be pulled.
>
> ___ You have too many commits attached to an e-mail; resend as threaded
>  commits, or place in a public tree for a pull.
>
> ___ You have resent this content multiple times without a clear indication
>  of what has changed between each re-send.
>
> ___ You have failed to adequately and individually address all of the
>  comments and change requests that were proposed in the initial review.
>
> ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)
>
> ___ Your computer have a badly configured date and time; confusing the
>  the threaded patch review.
>
> ___ Your changes affect IPC mechanism, and you don't present any results
>  for in-service upgradability test.
>
> ___ Your changes affect user manual and documentation, your patch series
>  do not contain the patch that updates the Doxygen manual.
>


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