[devel] [PATCH 1/1] base: Improve logging at daemon exit [#2704]

2017-11-24 Thread Hans Nordeback 
---
 src/base/daemon.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/src/base/daemon.c b/src/base/daemon.c
index 27170d779..bfb605093 100644
--- a/src/base/daemon.c
+++ b/src/base/daemon.c
@@ -68,6 +68,9 @@ static unsigned int __tracemask;
 static unsigned int __nofork = 0;
 static int __logmask;
 static int fifo_fd = -1;
+static pid_t sending_pid_ = -1;
+static uid_t sending_uid_ = -1;
+
 
 static void install_fatal_signal_handlers(void);
 
@@ -519,8 +522,11 @@ extern uint32_t ncs_sel_obj_ind(NCS_SEL_OBJ *i_ind_obj);
  * TERM signal handler
  * @param sig
  */
-static void sigterm_handler(int sig)
+static void sigterm_handler(int signum, siginfo_t *info, void *ptr)
 {
+   sending_pid_ = info->si_pid;
+   sending_uid_ = info->si_uid;
+
ncs_sel_obj_ind(_sel_obj);
signal(SIGTERM, SIG_IGN);
 }
@@ -534,7 +540,8 @@ static void sigterm_handler(int sig)
  */
 void daemon_exit(void)
 {
-   syslog(LOG_NOTICE, "exiting for shutdown");
+   syslog(LOG_NOTICE, "exiting for shutdown, (sigterm from pid %d uid %d)",
+   sending_pid_, sending_uid_);
 
close(fifo_fd);
 
@@ -551,13 +558,17 @@ void daemon_exit(void)
  */
 void daemon_sigterm_install(int *term_fd)
 {
+   struct sigaction act;
+
if (ncs_sel_obj_create(_sel_obj) != NCSCC_RC_SUCCESS) {
syslog(LOG_ERR, "ncs_sel_obj_create failed");
exit(EXIT_FAILURE);
}
 
-   if (signal(SIGTERM, sigterm_handler) == SIG_ERR) {
-   syslog(LOG_ERR, "signal TERM failed: %s", strerror(errno));
+   act.sa_sigaction = sigterm_handler;
+   act.sa_flags = SA_SIGINFO | SA_RESETHAND;
+   if (sigaction(SIGTERM, , NULL) < 0) {
+   syslog(LOG_ERR, "sigaction TERM failed: %s", strerror(errno));
exit(EXIT_FAILURE);
}
 
-- 
2.15.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 logging at daemon exit [#2704]

2017-11-24 Thread Hans Nordeback 
Summary: base: Improve logging at daemon exit [#2704]
Review request for Ticket(s): 2704
Peer Reviewer(s): AndersW, Ravi
Pull request to: 
Affected branch(es): develop
Development branch: ticket-2704
Base revision: b10634edc72a7b4523a1154b87b3c00703e71758
Personal repository: git://git.code.sf.net/u/hansnordeback/review


Impacted area   Impact y/n

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


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

revision 87b7ed739d5ea61f24ecf10cfa2e7dc5b82e748f
Author: Hans Nordeback 
Date:   Fri, 24 Nov 2017 15:23:52 +0100

base: Improve logging at daemon exit [#2704]



Complete diffstat:
--
 src/base/daemon.c | 19 +++
 1 file changed, 15 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 1/1] smf: SMF created a CCB to create smfRollbackElement object, but CCB was aborted due to IMM [#2676]

2017-11-24 Thread Vijay Roy 
Hi Lennart & Rafael,

 

Could you please check and provide ACK for this ticket[#2676] as spot fix. 

Since this is blocking our testing.

 

Note: As discussed we can take up refactoring changes separately in ticket 
#1398. 

 

Thanks

Vijay

 

From: Lennart Lund [mailto:lennart.l...@ericsson.com] 
Sent: Tuesday, November 21, 2017 1:51 PM
To: Vijay Roy ; Rafael Odzakow 
; Syam Prasad Talluri 
Cc: opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 1/1] smf: SMF created a CCB to create smfRollbackElement 
object, but CCB was aborted due to IMM [#2676]

 

Hi Vijay,

 

I forgot to mention that this is ticket #1398

 

/Lennart

 

From: Lennart Lund 
Sent: den 20 november 2017 13:33
To: Vijay Roy mailto:vijay@oracle.com"vijay@oracle.com>; 
Rafael Odzakow mailto:rafael.odza...@ericsson.com"rafael.odza...@ericsson.com>; HYPERLINK 
"mailto:syam.tall...@oracle.com"syam.tall...@oracle.com
Cc: HYPERLINK 
"mailto:opensaf-devel@lists.sourceforge.net"opensaf-devel@lists.sourceforge.net;
 Lennart Lund mailto:lennart.l...@ericsson.com"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]

 

Hi Vijay,

 

I have started to create a CCB handler handling all types of modifications of 
the IMM model where a CCB is involved (object create, modify and delete). It is 
created as a “separate module” that handles everything that has to do with IMM. 
This means, all steps involved in creating a CCB handling admin owner etc. It 
will do recovery when possible which includes everything from TRY_AGAIN to 
aborted CCB. It is handled using a well-defined and documented API. I will also 
include some shell commands that can be used as “demo” but also can be used for 
testing. These shell command will be built if –enable-tests is set when OpenSAF 
build is configured.

The plan is to replace all “inline” IMM handling regarding CCBs.

 

I have already implemented most of the code needed for a “create” and will soon 
start to test that part. When I have something that at least have some part 
working I will push for review and then push other parts for review in 
increments. In the mean time you can look at the API (as it looks so far). I 
have attached the .h file

 

Thanks

Lennart

 

From: Vijay Roy [mailto:vijay@oracle.com] 
Sent: den 20 november 2017 09:57
To: Lennart Lund mailto:lennart.l...@ericsson.com"lennart.l...@ericsson.com>; Rafael Odzakow 
mailto:rafael.odza...@ericsson.com"rafael.odza...@ericsson.com>; 
HYPERLINK "mailto:syam.tall...@oracle.com"syam.tall...@oracle.com
Cc: HYPERLINK 
"mailto:opensaf-devel@lists.sourceforge.net"opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 1/1] smf: SMF created a CCB to create smfRollbackElement 
object, but CCB was aborted due to IMM [#2676]

 

Hi Lennart,

 

In reality myself and Syam are also thinking on the same lines for refactoring 
CCB & Admin operations flows. 

In addition we need to have an eye on CLI & Customized Callback Actions. 

 

Better we discuss more in detail to baseline the solution. Please suggest. 

 

Regards

Vijay

 

 

From: Lennart Lund [mailto:lennart.l...@ericsson.com] 
Sent: Friday, November 17, 2017 9:47 PM
To: Vijay Roy mailto:vijay@oracle.com"vijay@oracle.com>; 
Rafael Odzakow mailto:rafael.odza...@ericsson.com"rafael.odza...@ericsson.com>; Lennart Lund 
mailto:lennart.l...@ericsson.com"lennart.l...@ericsson.com>
Cc: HYPERLINK 
"mailto:opensaf-devel@lists.sourceforge.net"opensaf-devel@lists.sourceforge.net
Subject: RE: [PATCH 1/1] smf: SMF created a CCB to create smfRollbackElement 
object, but CCB was aborted due to IMM [#2676]

 

Hi Vijay

 

It seems as this is getting a bit messy. These loops are added all over the 
place and (at least) in one case one of the loops did not work since it 
included a function that does more than one thing and at least one thing the 
function does did not fail the first time and can because of that not be done 
again even if some other part failed etc.

It seem as it is mostly IMM handling that is simplified so that possibilities 
of recovery is not used.

I think that if we continue to fix things like this we will soon lose control. 
I suggest that we do the following instead:

We need to handle recovery and “real” fails:

 

1. Creating CCBs:

Doing this is rather complicated if all rules shall be followed and all 
recovery possibilities shall be used.

In SMF this is done in many places and in most cases only TRY_AGAIN is handled 
(there is also a lot of redundant code), everything else is considered a Fail 
(will fail the campaign).

I am currently working on a “generic” solution  that can be used in all places 
where the IMM model shall be modified using a CCB. I think this is the most 
complicated part.

 

2. Admin operations:

This is also done in a simplified way in many places and in different

[devel] [PATCH 0/1] Review Request for base: create generic try-again handling decorator for AIS APIs [#2702]

2017-11-24 Thread Vu Minh Nguyen 
Summary: base: create generic try-again handling decorator for AIS APIs [#2702]
Review request for Ticket(s): 2702
Peer Reviewer(s): Hans, Anders
Pull request to: *** LIST THE PERSON WITH PUSH ACCESS HERE ***
Affected branch(es): develop
Development branch: ticket-2702
Base revision: b10634edc72a7b4523a1154b87b3c00703e71758
Personal repository: git://git.code.sf.net/u/winhvu/review


Impacted area   Impact y/n

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


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

revision d827ba30f2a5615992667023a341e0ecfa8e299d
Author: Vu Minh Nguyen 
Date:   Fri, 24 Nov 2017 17:24:26 +0700

base: create generic try-again handling decorator for AIS APIs [#2702]

Make generic C++ python-like decorator handling SA_AIS_ERR_TRY_AGAIN
return code of AIS APIs.



Added Files:

 src/base/tests/try_again_decorator_test.cc
 src/base/try_again_decorator.h


Complete diffstat:
--
 src/base/Makefile.am   |   5 +-
 src/base/tests/try_again_decorator_test.cc |  69 +++
 src/base/try_again_decorator.h | 131 +
 3 files changed, 204 insertions(+), 1 deletion(-)


Testing Commands:
-
Run `make check` at ~/src/base/


Testing, Expected Results:
--
All tests PASS


Conditions of Submission:
-
Ack from peer reviewers


Arch  Built StartedLinux distro
---
mipsn  n
mips64  n  n
x86 n  n
x86_64  n  n
powerpc n  n
powerpc64   n  n


Reviewer Checklist:
---
[Submitters: make sure that your review doesn't trigger any checkmarks!]


Your checkin has not passed review because (see checked entries):

___ Your RR template is generally incomplete; it has too many blank entries
that need proper data filled in.

___ You have failed to nominate the proper persons for review and push.

___ Your patches do not have proper short+long header

___ You have grammar/spelling in your header that is unacceptable.

___ You have exceeded a sensible line length in your headers/comments/text.

___ You have failed to put in a proper Trac Ticket # into your commits.

___ You have incorrectly put/left internal data in your comments/files
(i.e. internal bug tracking tool IDs, product names etc)

___ You have not given any evidence of testing beyond basic build tests.
Demonstrate some level of runtime or other sanity testing.

___ You have ^M present in some of your files. These have to be removed.

___ You have needlessly changed whitespace or added whitespace crimes
like trailing spaces, or spaces before tabs.

___ You have mixed real technical changes with whitespace and other
cosmetic code cleanup changes. These have to be separate commits.

___ You need to refactor your submission into logical chunks; there is
too much content into a single commit.

___ You have extraneous garbage in your review (merge commits etc)

___ You have giant attachments which should never have been sent;
Instead you should place your content in a public tree to be pulled.

___ You have too many commits attached to an e-mail; resend as threaded
commits, or place in a public tree for a pull.

___ You have resent this content multiple times without a clear indication
of what has changed between each re-send.

___ You have failed to adequately and individually address all of the
comments and change requests that were proposed in the initial review.

___ You have a misconfigured ~/.gitconfig file (i.e. user.name, user.email etc)

___ Your computer have a badly configured date and time; confusing the
the threaded patch review.

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

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


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

[devel] [PATCH 1/1] base: create generic try-again handling decorator for AIS APIs [#2702]

2017-11-24 Thread Vu Minh Nguyen 
Make generic C++ python-like decorator handling SA_AIS_ERR_TRY_AGAIN
return code of AIS APIs.
---
 src/base/Makefile.am   |   5 +-
 src/base/tests/try_again_decorator_test.cc |  69 +++
 src/base/try_again_decorator.h | 131 +
 3 files changed, 204 insertions(+), 1 deletion(-)
 create mode 100644 src/base/tests/try_again_decorator_test.cc
 create mode 100644 src/base/try_again_decorator.h

diff --git a/src/base/Makefile.am b/src/base/Makefile.am
index 956cce6..f11b738 100644
--- a/src/base/Makefile.am
+++ b/src/base/Makefile.am
@@ -150,6 +150,7 @@ noinst_HEADERS += \
src/base/unix_client_socket.h \
src/base/unix_server_socket.h \
src/base/unix_socket.h \
+   src/base/try_again_decorator.h \
src/base/usrbuf.h
 
 TESTS += bin/testleap bin/libbase_test bin/core_common_test
@@ -208,7 +209,9 @@ bin_libbase_test_SOURCES = \
src/base/tests/time_compare_test.cc \
src/base/tests/time_convert_test.cc \
src/base/tests/time_subtract_test.cc \
-   src/base/tests/unix_socket_test.cc
+   src/base/tests/unix_socket_test.cc \
+   src/base/tests/try_again_decorator_test.cc
+
 
 bin_libbase_test_LDADD = \
$(GTEST_DIR)/lib/libgtest.la \
diff --git a/src/base/tests/try_again_decorator_test.cc 
b/src/base/tests/try_again_decorator_test.cc
new file mode 100644
index 000..50ddf15
--- /dev/null
+++ b/src/base/tests/try_again_decorator_test.cc
@@ -0,0 +1,69 @@
+/*  -*- OpenSAF  -*-
+ *
+ * (C) Copyright 2017 The OpenSAF Foundation
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. This file and program are licensed
+ * under the GNU Lesser General Public License Version 2.1, February 1999.
+ * The complete license can be accessed from the following location:
+ * http://opensource.org/licenses/lgpl-license.php
+ * See the Copying file included with the OpenSAF distribution for full
+ * licensing terms.
+ *
+ * Author(s): Ericsson AB
+ *
+ */
+
+#define private public
+#include "base/try_again_decorator.h"
+#include "gtest/gtest.h"
+
+static unsigned count = 0;
+
+SaAisErrorT TestMethod() {
+  ++count;
+  return SA_AIS_ERR_TRY_AGAIN;
+}
+
+TEST(TryAgainDecorator, DecoratorFunction) {
+  auto DecorTestMethod = base::TryAgainDecorator(TestMethod);
+  DecorTestMethod();
+  EXPECT_GE(count, 200);
+  EXPECT_LE(count, 250);
+  count = 0;
+}
+
+TEST(TryAgainDecorator, DefaultRetryControl) {
+  auto DecorTestMethod = base::TryAgainDecorator(TestMethod);
+  timespec interval = DecorTestMethod.retry_ctrl_->interval;
+  uint64_t timeout = DecorTestMethod.retry_ctrl_->timeout;
+
+  EXPECT_EQ(interval.tv_sec, 0);
+  EXPECT_EQ(interval.tv_nsec, 40*1000*1000);
+  EXPECT_EQ(timeout, 10*1000);
+}
+
+TEST(TryAgainDecorator, UseLocalRetryControl) {
+  base::RetryControl ctrl({0, 60*1000}, 60);
+  auto DecorTestMethod = base::TryAgainDecorator(TestMethod, ctrl);
+  timespec interval = DecorTestMethod.retry_ctrl_->interval;
+  uint64_t timeout = DecorTestMethod.retry_ctrl_->timeout;
+
+  EXPECT_EQ(interval.tv_sec, 0);
+  EXPECT_EQ(interval.tv_nsec, 60*1000);
+  EXPECT_EQ(timeout, 60);
+}
+
+TEST(TryAgainDecorator, ChangeGlobalRetryControl) {
+  base::RetryControl ctrl({0, 100*1000}, 200);
+  auto DecorTestMethod = base::TryAgainDecorator(TestMethod);
+
+  base::ChangeGlobalRetryControl(ctrl);
+  timespec interval = DecorTestMethod.retry_ctrl_->interval;
+  uint64_t timeout = DecorTestMethod.retry_ctrl_->timeout;
+
+  EXPECT_EQ(interval.tv_sec, 0);
+  EXPECT_EQ(interval.tv_nsec, 100*1000);
+  EXPECT_EQ(timeout, 200);
+}
diff --git a/src/base/try_again_decorator.h b/src/base/try_again_decorator.h
new file mode 100644
index 000..1b648f4
--- /dev/null
+++ b/src/base/try_again_decorator.h
@@ -0,0 +1,131 @@
+/*  -*- OpenSAF  -*-
+ *
+ * Copyright Ericsson AB 2017 - All Rights Reserved.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. This file and program are licensed
+ * under the GNU Lesser General Public License Version 2.1, February 1999.
+ * The complete license can be accessed from the following location:
+ * http://opensource.org/licenses/lgpl-license.php
+ * See the Copying file included with the OpenSAF distribution for full
+ * licensing terms.
+ *
+ */
+
+#ifndef BASE_TRY_AGAIN_DECORATOR_H_
+#define BASE_TRY_AGAIN_DECORATOR_H_
+
+#include 
+#include 
+#include "base/time.h"
+#include "ais/include/saAis.h"
+
+namespace base {
+
+struct RetryControl {
+  // Sleep time b/w retries
+  timespec interval;
+  // Maximum time for retries (ms)
+  uint64_t timeout;
+
+  RetryControl() {
+interval = {0, 40*1000*1000};  // 40 miliseconds
+timeout  = 10*1000;// 10 seconds
+  }
+
+  explicit

Re: [devel] [PATCH 1/1] smf: SMF cannot distinguish swAdd and swRemove in same procedure [#2675]

2017-11-24 Thread 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 ; Vijay Roy 

*Cc:* Ravi Sekhar Reddy Konda ; Srinivas 
Mangipudy ; Lennart Lund 

*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  
*Cc:* Ravi Sekhar Reddy Konda 
; Syam Prasad Talluri
 ;
Srinivas Mangipudy 
; Lennart Lund
 
*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  
Cc: 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, please provide a campaign that
would case the ambiguity between nodes.

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

> Conditional