Re: [devel] [PATCH 1 of 1] log: implement SaLogFilterSetCallbackT [#2146]

2016-11-15 Thread Canh Truong
Hi Lennart, I already did the upgrade test as your below and it was passed from my side. I will check and run all test again Regards, Canh -Original Message- From: Lennart Lund [mailto:lennart.l...@ericsson.com] Sent: Tuesday, November 15, 2016 11:16 PM To: Canh Van Truong; Vu Minh

Re: [devel] [PATCH 1 of 1] fix crash problem by checking null pointer before accessing its detail

2016-11-15 Thread Vo Minh Hoang
Dear Mahesh, Thank you very much for your comments. Because the coredump occur when ckpt_node->node_users_cnt is not updated correctly to the number of node_user so we count here to handle that mismatch. Might it possible to keep using like currently? Sincerely, Hoang -Original

Re: [devel] [PATCH 1 of 1] fix crash problem by checking null pointer before accessing its detail

2016-11-15 Thread A V Mahesh
Hi Hoang Vo, >>Please let me know if you have any further inquiry. Can you please also make the fix more readable replace `for (count = 0; count < ckpt_node->node_users_cnt; count++) {` some thing like `for (node_user = ckpt_node->node_users; node_user != NULL; node_user = node_user->next) {`

Re: [devel] [PATCH 1 of 1] fix crash problem by checking null pointer before accessing its detail

2016-11-15 Thread A V Mahesh
Hi Hoang Vo, Can you please also make the fix more readable replace `for (count = 0; count < ckpt_node->node_users_cnt; count++) {` some thing like `for (node_user = ckpt_node->node_users; node_user != NULL; node_user = node_user->next) {` then, we can removevariable `int count = 0;`,

Re: [devel] [PATCH 1 of 1] fix crash problem by checking null pointer before accessing its detail

2016-11-15 Thread Vo Minh Hoang
Dear Mahesh, I am sorry that I cannot share the test steps because I cannot reproduce it in local environment. I've just received the coredump information point directly to this part, reviewed source code and found that pointer using is unsafe so I correct it. Please let me know if you have any

Re: [devel] [PATCH 1 of 1] fix crash problem by checking null pointer before accessing its detail

2016-11-15 Thread A V Mahesh
Hi Hoang Vo, On 11/15/2016 12:57 PM, Hoang Vo wrote: > Testing Commands: > - > > > Testing, Expected Results: > -- > Can you please share test case . -AVM On 11/15/2016 12:57 PM, Hoang Vo wrote: > osaf/services/saf/cpsv/cpd/cpd_red.c | 5 + > 1

[devel] Openstack

2016-11-15 Thread Guilherme Moro
Hi, Is there anyone working/planning/thinking anything related to Openstack and OpenSAF integration? I know that in the very basic there would be two scenarios, using OpenSAF to run Openstack itself (currently they use Pacemaker/corosync to achieve HA) and running OpenSAF within the VM's to

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

2016-11-15 Thread Alex Jones
Yes. I will not even consider pushing this until the AMF changes have been cleared, so they can both be tested together. Alex On 11/15/2016 02:28 AM, Neelakanta Reddy wrote: > > NOTICE: This email was received from an

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

2016-11-15 Thread Alex Jones
Hi Rafael, I'm still confused about this. What operations are you referring to after the fact? If the campaign does a lock or lock-instantiation after the software has been upgraded, these do not affect the operational state, and so they won't cause a problem here. Also, with this change, any

Re: [devel] [PATCH 1 of 1] log: implement SaLogFilterSetCallbackT [#2146]

2016-11-15 Thread Lennart Lund
Hi Canh I have done some testing and have found problems with compatibility between versions that will cause problems e.g. during an upgrade. I have used three nodes running different variants of OpenSAF 5.1 and default with your patch (5.2) and have found the following: All nodes running 5.2:

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

2016-11-15 Thread 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

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

2016-11-15 Thread Neelakanta Reddy
Hi Lennart, Reviewed the patch. Ack. /Neel. On 2016/11/15 02:07 PM, Lennart Lund wrote: > osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > > Fix a TRACE using %ld > > diff --git a/osaf/services/saf/smfsv/smfd/SmfUpgradeStep.cc >

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

2016-11-15 Thread 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 >

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

2016-11-15 Thread Lennart Lund
Summary: smf: Fix for #2066 does not build on 32bit Review request for Trac Ticket(s): [#2185] Peer Reviewer(s): reddy.neelaka...@oracle.com, rafael.odza...@ericsson.com Pull request to: Affected branch(es): 5.1 Development branch: <> Impacted area Impact

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

2016-11-15 Thread Lennart Lund
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 +++