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

[Gary Lee]

Hi Nagu

ack (review only)

Thanks

On 4/08/2016 3:20 PM, nagendr...@oracle.com wrote:
>   osaf/services/saf/amf/amfnd/susm.cc |  4 +++-
>   1 files changed, 3 insertions(+), 1 deletions(-)
>
>
> During component failover recovery (NPI SU), Amfnd
> attempt to send SUSI resp to Amfd though there is
> no SUSI assignment is undergoing.
> NPI SU terminating state is not a reflective of
> SUSI assignment rather it can be during recovery
> phases also.
>
> diff --git a/osaf/services/saf/amf/amfnd/susm.cc 
> b/osaf/services/saf/amf/amfnd/susm.cc
> --- a/osaf/services/saf/amf/amfnd/susm.cc
> +++ b/osaf/services/saf/amf/amfnd/susm.cc
> @@ -1832,7 +1832,9 @@ uint32_t avnd_su_pres_st_chng_prc(AVND_C
>   rc = avnd_di_oper_send(cb, su, 
> SA_AMF_COMPONENT_FAILOVER);
>   
>   /* si assignment/removal failed.. inform AvD */
> - rc = avnd_di_susi_resp_send(cb, su, 
> m_AVND_SU_IS_ALL_SI(su) ? 0 : si);
> + /* Send response to Amfd only when there is a pending 
> assignment. */
> + if (m_AVND_SU_IS_ASSIGN_PEND(su))
> + rc = avnd_di_susi_resp_send(cb, su, 
> m_AVND_SU_IS_ALL_SI(su) ? 0 : si);
>   }
>   
>   /* instantiating -> term-failed */


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

Re: [devel] [PATCH 1 of 1] amfd: create node group at std amfd if not existing [#1932]

[Gary Lee]

Hi Nagu

Would it be possible to reuse avd_ng_config_get()?

Thanks
Gary

On 4/08/2016 8:58 PM, nagendr...@oracle.com wrote:
>   osaf/services/saf/amf/amfd/nodegroup.cc |  35 
> +---
>   1 files changed, 31 insertions(+), 4 deletions(-)
>
>
> There are chances that node group addition may be
> missed at std amfd when added between config read and
> being applier.
> So, next command of adding a node in that node group
> will result in std amfd crash because node group
> doesnt exists at std amfd.
> So, it is better to re-read configuration at
> std amfd when node group is found null during
> node group modification (add/del of nodes).
>
> diff --git a/osaf/services/saf/amf/amfd/nodegroup.cc 
> b/osaf/services/saf/amf/amfd/nodegroup.cc
> --- a/osaf/services/saf/amf/amfd/nodegroup.cc
> +++ b/osaf/services/saf/amf/amfd/nodegroup.cc
> @@ -551,10 +551,37 @@ static void ng_ccb_apply_modify_hdlr(Ccb
>   unsigned j = 0;
>   const SaImmAttrModificationT_2 *mod;
>   AVD_AMF_NG *ng;
> -
> + SaAisErrorT rc;
> + const SaImmAttrValuesT_2 **attributes;
> + SaImmAccessorHandleT accessorHandle;
>   TRACE_ENTER();
>   
>   ng = avd_ng_get(>objectName);
> + if (ng == nullptr) {
> + TRACE("%p", ng);
> + /* During Standby cold sync, there may be chance that
> +node group creation was missed in-between config read
> +and being applier, so re-read config again.
> +Once it is read, then below ADD/DEL logic may not be
> +needed because config will be the latest, but just keeping
> +because they are not causing any harm.*/
> + immutil_saImmOmAccessorInitialize(avd_cb->immOmHandle, 
> );
> + rc = immutil_saImmOmAccessorGet_2(accessorHandle, 
> >objectName,
> + nullptr, (SaImmAttrValuesT_2 ***));
> + if (rc != SA_AIS_OK) {
> + LOG_ER("saImmOmAccessorGet_2 FAILED %u for %s", rc, 
> opdata->objectName.value);
> + goto done;
> + }
> + TRACE("'%s'", opdata->objectName.value);
> + if ((ng = ng_create(>objectName, attributes)) == 
> nullptr) {
> + LOG_ER("ng_create failed for %s", 
> opdata->objectName.value);
> + goto done;
> + }
> + nodegroup_db->insert(Amf::to_string(>name), ng);
> + TRACE("ng '%s' created with number_nodes '%u'", ng->name.value,
> + ng->number_nodes());
> + immutil_saImmOmAccessorFinalize(accessorHandle);
> + }
>   
>   while ((mod = opdata->param.modify.attrMods[i++]) != nullptr) {
>   switch (mod->modType) {
> @@ -563,7 +590,7 @@ static void ng_ccb_apply_modify_hdlr(Ccb
>   
> ng->saAmfNGNodeList.insert(Amf::to_string((SaNameT*)mod->modAttr.attrValues[j]));
>   }
>   
> - TRACE("number_nodes %u", ng->number_nodes());
> + TRACE("number_nodes after addition %u", 
> ng->number_nodes());
>   break;
>   }
>   case SA_IMM_ATTR_VALUES_DELETE: {
> @@ -572,14 +599,14 @@ static void ng_ccb_apply_modify_hdlr(Ccb
>   
> ng->saAmfNGNodeList.erase(Amf::to_string((SaNameT*)mod->modAttr.attrValues[j]));
>   }
>   
> - TRACE("number_nodes %u", ng->number_nodes());
> + TRACE("number_nodes left after deletion %u", 
> ng->number_nodes());
>   break;
>   }
>   default:
>   osafassert(0);
>   }
>   }
> -
> +done:
>   TRACE_LEAVE();
>   }
>   


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

[devel] [PATCH 0 of 1] Review Request for AMFD: Correct setting SU in-server [#1938]

[Minh Hon Chau]

Summary: AMFD: Correct setting SU in-server [#1938]
Review request for Trac Ticket(s): 1938
Peer Reviewer(s): AMF maintainers
Pull request to: <>
Affected branch(es): 5.0, 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 f197ce506dcbacf9184d7de0c3b7d69365349842
Author: minh-chau 
Date:   Wed, 17 Aug 2016 14:01:19 +1000

AMFD: Correct setting SU in-server [#1938]

In SU repair scenario, the SU readiness state is currently set to 
IN_SERVICE
in avd_data_update_req_evh(). And later on, avd_su_oper_state_evh() 
sets SU
readiness state back to OUT_OF_SERVICE. This logic is redundant and SU
readiness state should not be set while updating SU' oper state to align
with non-headless logic.

Patch removes that incorrect setting of SU's readiness state


Complete diffstat:
--
 osaf/services/saf/amf/amfd/ndproc.cc |   4 
 osaf/services/saf/amf/amfd/sgproc.cc |  14 --
 2 files changed, 0 insertions(+), 18 deletions(-)


Testing Commands:
-
 <>


Testing, Expected Results:
--
 <>


Conditions of Submission:
-
 ack


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


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


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

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

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

___ Your patches do not have proper short+long header

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

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

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

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

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

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

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

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

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

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

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

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

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

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

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

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

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

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


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

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

[minh chau]

Hi Nagu,

I got this.

   CXX  osafamfd-sg_2n_fsm.o
   CXX  osafamfd-sg_nored_fsm.o
sg_2n_fsm.cc: In member function ‘virtual SaAisErrorT 
SG_2N::si_swap(AVD_SI*, SaInvocationT)’:
sg_2n_fsm.cc:775:6: error: ‘cb’ was not declared in this scope
 ((cb->node_id_avd_other != 0) && (cb->other_avd_adest != 0))) {
   ^
Makefile:1176: recipe for target 'osafamfd-sg_2n_fsm.o' failed
make[7]: *** [osafamfd-sg_2n_fsm.o] Error 1

Thanks,
Minh

On 16/08/16 19:32, Nagendra Kumar wrote:
> Please review it by this weekend.
>
> Thanks
> -Nagu
>
>> -Original Message-
>> From: Nagendra Kumar
>> Sent: 02 August 2016 17:34
>> To: hans.nordeb...@ericsson.com; Praveen Malviya;
>> minh.c...@dektech.com.au; gary@dektech.com.au
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: [devel] [PATCH 1 of 1] amfd: mark stby_sync_state out of sync if
>> peer amfd is absent [#1850]
>>
>>   osaf/services/saf/amf/amfd/main.cc  |  2 +-
>>   osaf/services/saf/amf/amfd/sg_2n_fsm.cc |  3 ++-
>>   osaf/services/saf/amf/amfd/sgproc.cc|  8 +---
>>   3 files changed, 4 insertions(+), 9 deletions(-)
>>
>>
>> If standby amfd is not available then stby_sync_state should be in out of 
>> sync
>> state.
>> Else, Amfd should be in out of sync state.
>> This is to avoid issues like 1841
>>
>> diff --git a/osaf/services/saf/amf/amfd/main.cc
>> b/osaf/services/saf/amf/amfd/main.cc
>> --- a/osaf/services/saf/amf/amfd/main.cc
>> +++ b/osaf/services/saf/amf/amfd/main.cc
>> @@ -542,7 +542,7 @@ static uint32_t initialize(void)
>>  cb->fully_initialized = false;
>>  cb->swap_switch = false;
>>  cb->active_services_exist = true;
>> -cb->stby_sync_state = AVD_STBY_IN_SYNC;
>> +cb->stby_sync_state = AVD_STBY_OUT_OF_SYNC;
>>  cb->sync_required = true;
>>
>>  cb->heartbeat_tmr.is_active = false;
>> diff --git a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
>> b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
>> --- a/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
>> +++ b/osaf/services/saf/amf/amfd/sg_2n_fsm.cc
>> @@ -771,7 +771,8 @@ SaAisErrorT SG_2N::si_swap(AVD_SI *si, S
>>  goto done;
>>  }
>>
>> -if (si->sg_of_si->sg_ncs_spec) {
>> +if ((si->sg_of_si->sg_ncs_spec) &&
>> +((cb->node_id_avd_other != 0) && (cb-
>>> other_avd_adest != 0))) {
>>  if (avd_cb->stby_sync_state == AVD_STBY_OUT_OF_SYNC) {
>>  LOG_ER("%s SWAP failed - Cold sync in progress", si-
>>> name.value);
>>  rc = SA_AIS_ERR_TRY_AGAIN;
>> diff --git a/osaf/services/saf/amf/amfd/sgproc.cc
>> b/osaf/services/saf/amf/amfd/sgproc.cc
>> --- a/osaf/services/saf/amf/amfd/sgproc.cc
>> +++ b/osaf/services/saf/amf/amfd/sgproc.cc
>> @@ -1997,14 +1997,8 @@ void avd_node_down_mw_susi_failover(AVD_
>>  if ((i_su->sg_of_su->sg_redundancy_model ==
>> SA_AMF_2N_REDUNDANCY_MODEL) &&
>>  (i_su->sg_of_su->sg_fsm_state ==
>> AVD_SG_FSM_STABLE))
>>  (void) avd_clm_track_start();
>> -/* If Std ctlr went down in middle of Cold sync, then we need
>> -   to reset the sync state to IN_SYNC. */
>> -if ((i_su->sg_of_su->sg_redundancy_model ==
>> SA_AMF_2N_REDUNDANCY_MODEL) &&
>> -(cb->stby_sync_state ==
>> AVD_STBY_OUT_OF_SYNC)) {
>> -TRACE("Marking sync_state as in_sync");
>> -cb->stby_sync_state = AVD_STBY_IN_SYNC;
>> -}
>>  /* Free all the SU SI assignments*/
>> +
>>  i_su->delete_all_susis();
>>
>>  }   /* for (const auto& i_su : avnd->list_of_su) */
>>
>> --
>> ___
>> Opensaf-devel mailing list
>> Opensaf-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel


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

Re: [devel] [PATCH 0 of 1] Review Request for imm: Add readme for SC absence feature [#1856]

[Neelakanta Reddy]

Hi Zoran,

Reviewed the patch.
Ack.

/Neel.

On 2016/08/16 04:22 PM, Hung Nguyen wrote:
> Summary: imm: Add readme for SC absence feature [#1856]
> Review request for Trac Ticket(s): 1856
> Peer Reviewer(s): Zoran, Neel
> Pull request to:
> Affected branch(es): 5.0, 5.1
> Development branch: 5.1
>
> 
> Impacted area   Impact y/n
> 
>   Docsn
>   Build systemn
>   RPM/packaging   n
>   Configuration files n
>   Startup scripts n
>   SAF servicesy
>   OpenSAF servicesn
>   Core libraries  n
>   Samples n
>   Tests   n
>   Other   n
>
>
> Comments (indicate scope for each "y" above):
> -
>
>
> changeset 8a64c9e37a03c81ddbfc836ad0f0c3530cf695c1
> Author:   Hung Nguyen 
> Date: Tue, 16 Aug 2016 17:50:26 +0700
>
>   imm: Add readme for SC absence feature [#1856]
>
>   Add readme for SC absence feature.
>
>
> Added Files:
> 
>   osaf/services/saf/immsv/README.SC_ABSENCE
>
>
> Complete diffstat:
> --
>   osaf/services/saf/immsv/README|   2 ++
>   osaf/services/saf/immsv/README.SC_ABSENCE |  78 
> ++
>   2 files changed, 80 insertions(+), 0 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 imm: Add readme for SC absence feature [#1856]

[Zoran Milinkovic]

Hi Hung,

Reviewed the patch.
Ack from me.

Thanks,
Zoran

-Original Message-
From: Hung Nguyen [mailto:hung.d.ngu...@dektech.com.au] 
Sent: den 16 augusti 2016 12:52
To: Zoran Milinkovic; reddy.neelaka...@oracle.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 0 of 1] Review Request for imm: Add readme for SC absence 
feature [#1856]

Summary: imm: Add readme for SC absence feature [#1856]
Review request for Trac Ticket(s): 1856
Peer Reviewer(s): Zoran, Neel
Pull request to:
Affected branch(es): 5.0, 5.1
Development branch: 5.1


Impacted area   Impact y/n

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


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


changeset 8a64c9e37a03c81ddbfc836ad0f0c3530cf695c1
Author: Hung Nguyen 
Date:   Tue, 16 Aug 2016 17:50:26 +0700

imm: Add readme for SC absence feature [#1856]

Add readme for SC absence feature.


Added Files:

 osaf/services/saf/immsv/README.SC_ABSENCE


Complete diffstat:
--
 osaf/services/saf/immsv/README|   2 ++
 osaf/services/saf/immsv/README.SC_ABSENCE |  78 
++
 2 files changed, 80 insertions(+), 0 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

[devel] [PATCH 1 of 1] imm: Add readme for SC absence feature [#1856]

[Hung Nguyen]

 osaf/services/saf/immsv/README|   2 +
 osaf/services/saf/immsv/README.SC_ABSENCE |  78 +++
 2 files changed, 80 insertions(+), 0 deletions(-)


Add readme for SC absence feature.

diff --git a/osaf/services/saf/immsv/README b/osaf/services/saf/immsv/README
--- a/osaf/services/saf/immsv/README
+++ b/osaf/services/saf/immsv/README
@@ -2779,6 +2779,8 @@ provided during absent SC depends on the
 of the IMM service, the service provided during SC absence is in essence 
 only the reading of config data.
 
+See: osaf/services/saf/immsv/README.SC_ABSENCE for details.
+
 
 Add attribute definition flag SA_IMM_ATTR_STRONG_DEFAULT (5.0)
 ===
diff --git a/osaf/services/saf/immsv/README.SC_ABSENCE 
b/osaf/services/saf/immsv/README.SC_ABSENCE
new file mode 100644
--- /dev/null
+++ b/osaf/services/saf/immsv/README.SC_ABSENCE
@@ -0,0 +1,78 @@
+SC ABSENCE: Allow IMMNDs to survive SC absence (5.0)
+
+Prior to this enhancement, absence of both SCs will cause IMMNDs to restart,
+also the cluster will be reboot by AMF. With this feature, IMMNDs on payloads
+continue to provide limited service until an SC is back.
+
+
+CONFIGURATION
+=
+To enable this feature, IMMSV_SC_ABSENCE_ALLOWED environment variable must be
+set for IMMD (immd.conf)
+
+export IMMSV_SC_ABSENCE_ALLOWED=900
+
+The value indicates the number of seconds cluster will tolerate SC absence,
+value of zero indicates the feature is disabled.
+See immd.conf for more details.
+
+
+IMMND
+=
+With SC absence feature enabled, IMMNDs on payloads now can be coordinator.
+That can happen even when the SCs are not absent.
+
+For example, the cluster only has one SC and IMMND on SC restarts, one of the
+IMMNDs on payloads will be elected as new coordinator. Without SC absence
+enabled, the cluster will not tolerate that situation and a cluster reboot will
+occur.
+
+If PBE is configured together with this feature, make sure that the shared file
+system (where sqlite database is located) is accessible from all nodes of the
+cluster.
+
+Upon receiving the IMMD down event, payload based IMMNDs unregister with MDS
+and then:
+- remove all local clients,
+- discard all implementers,
+- finalize all admin owners,
+- abort all non-critical CCBs.
+
+That means the IMMNDs only keep class definitions and object information in
+their memories during SC absence.
+
+After cleaning up those things, MDS will be registered again to allow clients 
to
+read the objects but only config data can be read because there's currently no
+OI attached for runtime data.
+
+Other operations with IMM service will get SA_AIS_ERR_TRY_AGAIN during SC
+absence.
+If you retry the APIs on SA_AIS_ERR_TRY_AGAIN, you should retry at least the
+amount of time that you set for IMMSV_SC_ABSENCE_ALLOWED.
+
+If you get SA_AIS_ERR_BAD_HANDLE, you must re-initialize the handles.
+
+
+IMMD
+
+After coming back from SC absence, the active IMMD will wait for the veteran
+IMMNDs to introduce for 3 seconds. If there's no introduction from veteran 
IMMND
+within 3 seconds, IMMD will start to load from repository. This is to avoid the
+race condition where IMMD receives and processes introduce message from the
+local IMMND or a newly joined IMMND before the veteran IMMNDs.
+
+The veteran IMMNDs also include highest fevs, latest id of implementer/admo/ccb
+in the introduce message to help IMMD restore these counters back to the state
+right before SC absence.
+
+IMMD then elects one of the veteran IMMNDs as new coordinator and the data is
+sync'ed to the SC based IMMNDs. After that, IMM service becomes fully 
functional
+again.
+
+
+SC ABSENCE and 2PBE
+===
+Support for absent IMMD is incompatible with 2PBE. If both are configured then
+2PBE will win and the absence of IMMD feature will be ignored. An error message
+is printed in this case to the syslog at startup.
+

--
___
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 imm: Add readme for SC absence feature [#1856]

[Hung Nguyen]

Summary: imm: Add readme for SC absence feature [#1856]
Review request for Trac Ticket(s): 1856
Peer Reviewer(s): Zoran, Neel
Pull request to:
Affected branch(es): 5.0, 5.1
Development branch: 5.1


Impacted area   Impact y/n

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


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


changeset 8a64c9e37a03c81ddbfc836ad0f0c3530cf695c1
Author: Hung Nguyen 
Date:   Tue, 16 Aug 2016 17:50:26 +0700

imm: Add readme for SC absence feature [#1856]

Add readme for SC absence feature.


Added Files:

 osaf/services/saf/immsv/README.SC_ABSENCE


Complete diffstat:
--
 osaf/services/saf/immsv/README|   2 ++
 osaf/services/saf/immsv/README.SC_ABSENCE |  78 
++
 2 files changed, 80 insertions(+), 0 deletions(-)


Testing Commands:
-



Testing, Expected Results:
--



Conditions of Submission:
-
Ack from reviewers.


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


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


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

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

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

___ Your patches do not have proper short+long header

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

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

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

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

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

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

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

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

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

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

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

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

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

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

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

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

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

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


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

Re: [devel] [PATCH 1 of 5] amfd: replace SaNameT with string in include dir [#1642]

[Long Nguyen]

Hi Praveen,

Yes, the option 3 has a problem to make the names to be unique.
For the option 2, I agree that it will be complex.
We would like to understand more in the situation. Why do we need to 
support adding csi (long DN) dynamically to an application (does not 
support long DN) while we can add a normal (short) csi instead?
Can you please share with us the scenario?

Best regards,
Long Nguyen.

On 8/16/2016 4:19 PM, praveen malviya wrote:
>
>
> On 15-Aug-16 5:05 PM, Long Nguyen wrote:
>> Hi Praveen,
>>
>> Thanks for your suggestions.
>> Please see my comments marked with [Long[.
>>
>> Best regards,
>> Long Nguyen.
>>
>> On 8/12/2016 5:03 PM, praveen malviya wrote:
>>>
>>>
>>> On 12-Aug-16 1:27 PM, Long Nguyen wrote:
 Hi Praveen,

 Actually, since Anders introduced the extended SaNameT in leap 
 core, he
 also added the osaf_extended_name_init() into leap.
 Amf agent uses  leap library (i.e. saAmfInitialize()). So, 
 applications
 under amf control enabled long DN implicitly.
 The SA_AIS_ERR_NAME_TOO_LONG return code is not returned in our case
 (still SA_AIS_OK) due to the above reason. Consequently, the
 applications are not crashed.

 I am not sure if it is right to add osaf_extended_name_init() into 
 leap.
 However, it is the case now.

>>> Addition of osaf_extended_name_init()  into leap is right because
>>> every agent has to support long and short dn applications. But
>>> osaf_extended_name_init() distinguish a long or short dn application
>>> based on whether application has set "SA_ENABLE_EXTENDED_NAMES" or
>>> not.If you see the implementation of this API, based on this exported
>>> variable it remembers whether application is a long dn one or short dn
>>> one. For this only only applications are recommended via documentation
>>> to set this environment variable before calling any SAF API if they
>>> want handle longdn.In this way when first SAF API is called (generally
>>> sa,*>Initialize()), leap initialization will be done as a part of
>>> agent creation. Inside leap init it will call
>>> osaf_extended_name_init() which will use the environment variable to
>>> remember about the nature of application.
>>>
>>> The idea of CCB rejection was based on this only that an agent knows
>>> via osaf_extended_* APIs that it is created by a longdn or shortdn
>>> application. And this information can be passed to amfnd and hence to
>>> AMFD.
>>>
>>> But now what needs to be explored is why AMF Dispatch() is not
>>> returning NAME_TOO_LONG when you have already coded for it? Since old
>>> AMF demo has not enabled long dn, Dispatch() must return this error 
>>> code.
>>> Is there any problem with ava_sanamet_is_valid()?
>>> Let us debug that.
>>>
>>>
 Can you please share with us your ideas? Do we still need to truncate
 long names in this case?
>>> As we have discussed, rejection of CCB can be postponed as it requires
>>> new messages or introduction of new fields in old messages, all the
>>> way from AMFA to AMFD.
>>> So we are left with three options:
>>> 1) Dispatch() will return NAME_TOO_LONG without invoking callback.
>>> Current patch is doing this.
>>> This has one disadvantage that comp/application may exit/crash.
>>> 2)Dispatch will return SA_AIS_OK "without" invoking the callback.
>>> This will not confuse application.
>>> There is one disadvantage here, AMF has an illegal COMPCSI.
>>> 3)Dispatch will return SA_AIS_OK "by" invoking the callback with
>>> truncated values.
>>> This has one advantage that AMF does not have illegal COMPCSI.
>>> One disadvantage is that if comp is serving more CSI and then it
>>> will not be able to rightly distinguish between the CSI names.
>>>
>>> Option 2) sounds Ok to me as it will not create problems with
>>> application as AMF is not invoking any callback and atleast
>>> application is serving existing CSIs. Regarding the illegal COMPCSI in
>>> AMF: A user can always delete it and deletion will not again result in
>>> CSI remove callback because of the same reasons. At the same time we
>>> are cautioning the user via documentation (REAMDME and PR doc).
>>> [Long] I think the option 3 is better than the option 2. If we ignore
>>> the callback, amf does not receive the responses from applications and
>>> then applications get restarted due to callback timeout.
>>>
> [Praveen] That was the problem with the current patch also, in which 
> callback is not invoked and NAME_TOO_LONG is returned in dispatch(). 
> So AMFND was already getting time out for the callback.
>
> For option 2) there can be other consideration like generating fake 
> Response() to AMFND or blocking the callback at AMFND itself (I was 
> trying this blocking at amfnd approach crude patch in attachment. From 
> agent to amfnd it is flat encode/decode advantage. But this needs to 
> be explored further and will be complex. But it can act as first step 
> towards CCB rejection.).
> For option 3) how the 

Re: [devel] [PATCH 1 of 1] log: fix ER in syslog if changing saLogStreamFileName and other atrributes[#1887]

[A V Mahesh]

Hi,

ACK , tested

Please re-base before publishing.

-AVM


On 8/4/2016 9:36 AM, Canh Van Truong wrote:
>   osaf/services/saf/logsv/lgs/lgs_imm.cc |  52 
> +-
>   1 files changed, 26 insertions(+), 26 deletions(-)
>
>
> When changing saLogStreamFileName  with other attributes, the action
> "closing current log file", "rename", "create new cfg and log file" are
> duplicated. This cause the ER in syslog, because lgsv can not find log
> file when closing secondly. Name of current log file was changed at first 
> time.
>
> This patch make lgsv just do above action only once.
>
> diff --git a/osaf/services/saf/logsv/lgs/lgs_imm.cc 
> b/osaf/services/saf/logsv/lgs/lgs_imm.cc
> --- a/osaf/services/saf/logsv/lgs/lgs_imm.cc
> +++ b/osaf/services/saf/logsv/lgs/lgs_imm.cc
> @@ -2275,7 +2275,7 @@ static void stream_ccb_apply_modify(cons
>   bool new_cfg_file_needed = false;
>   struct timespec curtime_tspec;
>   std::string fileName;
> - bool modify = false;
> + bool stream_filename_modified = false;
>   
>   TRACE_ENTER2("CCB ID %llu, '%s'", opdata->ccbId, 
> opdata->objectName.value);
>   
> @@ -2295,7 +2295,7 @@ static void stream_ccb_apply_modify(cons
>   
>   if (!strcmp(attribute->attrName, "saLogStreamFileName")) {
>   fileName = *((char **)value);
> - modify = true;
> + stream_filename_modified = true;
>   } else if (!strcmp(attribute->attrName, 
> "saLogStreamMaxLogFileSize")) {
>   SaUint64T maxLogFileSize = *((SaUint64T *)value);
>   stream->maxLogFileSize = maxLogFileSize;
> @@ -2337,7 +2337,30 @@ static void stream_ccb_apply_modify(cons
>   time_t cur_time = curtime_tspec.tv_sec;
>   std::string root_path = static_cast *>(lgs_cfg_get(LGS_IMM_LOG_ROOT_DIRECTORY));
>   
> - if (new_cfg_file_needed) {
> + /* Fix for ticket #1346 */
> + if (stream_filename_modified) {
> + int rc;
> + if ((rc = log_stream_config_change(!LGS_STREAM_CREATE_FILES,
> + root_path, stream, current_logfile_name, _time))
> + != 0) {
> + LOG_ER("log_stream_config_change failed: %d", rc);
> + }
> +
> + stream->fileName = fileName;
> +
> + if ((rc = lgs_create_config_file_h(root_path, stream)) != 0) {
> + LOG_ER("lgs_create_config_file_h failed: %d", rc);
> + }
> +
> + char *current_time = lgs_get_time(_time);
> + stream->logFileCurrent = stream->fileName + "_" + current_time;
> +
> + // Create the new log file based on updated configuration
> + if ((*stream->p_fd = log_file_open(root_path,
> + stream, stream->logFileCurrent, NULL)) == -1)
> + LOG_ER("New log file could not be created for stream: 
> %s",
> + stream->name);
> + } else if (new_cfg_file_needed) {
>   int rc;
>   if ((rc = log_stream_config_change(LGS_STREAM_CREATE_FILES,
>   root_path, stream,
> @@ -2347,29 +2370,6 @@ static void stream_ccb_apply_modify(cons
>   }
>   }
>   
> - /* Fix for ticket #1346 */
> - if (modify) {
> - int rc;
> - if ((rc = log_stream_config_change(!LGS_STREAM_CREATE_FILES,
> - root_path, stream, current_logfile_name, _time))
> - != 0) {
> - LOG_ER("log_stream_config_change failed: %d", rc);
> - }
> -
> - stream->fileName = fileName;
> -
> - if ((rc = lgs_create_config_file_h(root_path, stream)) != 0) {
> - LOG_ER("lgs_create_config_file_h failed: %d", rc);
> - }
> -
> - char *current_time = lgs_get_time(_time);
> - stream->logFileCurrent = stream->fileName + "_" + current_time;
> -
> - // Create the new log file based on updated configuration
> - *stream->p_fd = log_file_open(root_path,
> - stream, stream->logFileCurrent, NULL);
> - }
> -
>   /* Checkpoint to standby LOG server */
>   /* Save time change was done for standby */
>   stream->act_last_close_timestamp = cur_time;


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

[devel] [PATCH 1 of 1] log: assertion failed in log_stream_close [#1954]

[Vu Minh Nguyen]

 osaf/services/saf/logsv/lgs/lgs_evt.cc |  4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)


Assertion failed in log_stream_close() because the caller did not check NULL
before calling the function.

This patch adds the protection.

diff --git a/osaf/services/saf/logsv/lgs/lgs_evt.cc 
b/osaf/services/saf/logsv/lgs/lgs_evt.cc
--- a/osaf/services/saf/logsv/lgs/lgs_evt.cc
+++ b/osaf/services/saf/logsv/lgs/lgs_evt.cc
@@ -166,7 +166,9 @@ int lgs_client_delete(uint32_t client_id
lgs_stream_list_t *tmp_rec;
log_stream_t *stream = log_stream_get_by_id(cur_rec->stream_id);
TRACE_4("client_id: %u, REMOVE stream id: %u", 
client->client_id, cur_rec->stream_id);
-   log_stream_close(, );
+   if (stream != NULL) {
+   log_stream_close(, );
+   }
tmp_rec = cur_rec->next;
free(cur_rec);
cur_rec = tmp_rec;

--
___
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 log: assertion failed in log_stream_close [#1954]

[Vu Minh Nguyen]

Summary: log: assertion failed in log_stream_close [#1954]
Review request for Trac Ticket(s): #1954
Peer Reviewer(s): Lennart, Mahesh
Pull request to: <>
Affected branch(es): all branches
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 feca45f4392f8473e2099e290997402c23efae83
Author: Vu Minh Nguyen 
Date:   Tue, 16 Aug 2016 16:59:25 +0700

log: assertion failed in log_stream_close [#1954]

Assertion failed in log_stream_close() because the caller did not check 
NULL
before calling the function.

This patch adds the protection.


Complete diffstat:
--
 osaf/services/saf/logsv/lgs/lgs_evt.cc |  4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)


Testing Commands:
-
 <>


Testing, Expected Results:
--
 <>


Conditions of Submission:
-
 Get 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 ~/.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] clm: fix string format for size_t type [#1906]

[A V Mahesh]

Hi Zoran,

ACK Not tested.

-AVM


On 8/16/2016 3:01 PM, Zoran Milinkovic wrote:
>   osaf/services/saf/clmsv/clms/clms_imm.c |  2 +-
>   1 files changed, 1 insertions(+), 1 deletions(-)
>
>
> Fix string format for size_t type, so that 32-bit compilers can compile 
> OpenSAF without errors.
>
> diff --git a/osaf/services/saf/clmsv/clms/clms_imm.c 
> b/osaf/services/saf/clmsv/clms/clms_imm.c
> --- a/osaf/services/saf/clmsv/clms/clms_imm.c
> +++ b/osaf/services/saf/clmsv/clms/clms_imm.c
> @@ -225,7 +225,7 @@ CLMS_CLUSTER_NODE *clms_node_new(SaNameT
>   SaNameT *name = (SaNameT *)value;
>   size_t nameLen = osaf_extended_name_length(name);
>   
> - TRACE("saClmNodeEE attribute name's length %lu", 
> nameLen);
> + TRACE("saClmNodeEE attribute name's length %zu", 
> nameLen);
>   
>   if (nameLen != 0) {
>   if (nameLen >= SA_MAX_NAME_LENGTH) {
>
> --
> ___
> 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] ntfsv: refactor logging long dn notification [#1585]

[praveen malviya]

Ack.

Thanks,
Praveen

On 11-Aug-16 2:03 PM, Vu Minh Nguyen wrote:
>  osaf/services/saf/ntfsv/ntfs/NtfLogger.cc   |   51 +-
>  tests/ntfsv/tet_longDnObject_notification.c |  188 
> +++-
>  2 files changed, 196 insertions(+), 43 deletions(-)
>
>
> Remove the part of code that truncates the long DN.
> And update the long DN test suite (#36) to make sure full record logged.
>
> diff --git a/osaf/services/saf/ntfsv/ntfs/NtfLogger.cc 
> b/osaf/services/saf/ntfsv/ntfs/NtfLogger.cc
> --- a/osaf/services/saf/ntfsv/ntfs/NtfLogger.cc
> +++ b/osaf/services/saf/ntfsv/ntfs/NtfLogger.cc
> @@ -21,6 +21,7 @@
>   */
>  #include 
>
> +#include "osaf_utility.h"
>  #include "saAis.h"
>  #include "saLog.h"
>  #include "NtfAdmin.hh"
> @@ -232,48 +233,22 @@ SaAisErrorT NtfLogger::logNotification(N
> notif->getNotificationId(),
> SA_LOG_RECORD_WRITE_ACK,
> );
> -if (SA_AIS_OK != errorCode) {
> -  LOG_NO("Failed to log an alarm or security alarm notification (%d)", 
> errorCode);
> -  if (errorCode == SA_AIS_ERR_LIBRARY || errorCode == 
> SA_AIS_ERR_BAD_HANDLE) {
> -LOG_ER("Fatal error SA_AIS_ERR_LIBRARY or SA_AIS_ERR_BAD_HANDLE; 
> exiting (%d)...", errorCode);
> -exit(EXIT_FAILURE);
> -  } else if (errorCode == SA_AIS_ERR_INVALID_PARAM) {
> -/* Retry to log truncated notificationObject/notifyingObject because
> - * LOG Service has not supported long dn in Opensaf 4.5
> - */
> -char short_dn[SA_MAX_UNEXTENDED_NAME_LENGTH];
> -memset(_dn, 0, SA_MAX_UNEXTENDED_NAME_LENGTH);
> -SaNameT shortdn_notificationObject, shortdn_notifyingObject;
> -if (osaf_is_an_extended_name(ntfHeader->notificationObject)) {
> -  strncpy(short_dn, 
> osaf_extended_name_borrow(ntfHeader->notificationObject)
> -  , SA_MAX_UNEXTENDED_NAME_LENGTH - 1);
> -  osaf_extended_name_lend(short_dn, _notificationObject);
> -  logRecord.logHeader.ntfHdr.notificationObject = 
> _notificationObject;
> -}
> -if (osaf_is_an_extended_name(ntfHeader->notifyingObject)) {
> -  strncpy(short_dn, 
> osaf_extended_name_borrow(ntfHeader->notifyingObject)
> -  , SA_MAX_UNEXTENDED_NAME_LENGTH - 1);
> -  osaf_extended_name_lend(short_dn, _notifyingObject);
> -  logRecord.logHeader.ntfHdr.notifyingObject = 
> _notifyingObject;
> -}
> -if (short_dn[0] != '\0') {
> -  LOG_NO("Retry to log the truncated 
> notificationObject/notifyingObject");
> -  if ((errorCode = saLogWriteLogAsync(alarmStreamHandle,
> -  notif->getNotificationId(),
> -  SA_LOG_RECORD_WRITE_ACK,
> -  )) != SA_AIS_OK) {
> -LOG_ER("Failed to log the truncated 
> notificationObject/notifyingObject (%d)"
> -   , errorCode);
> -  }
> -}
> -  }
> -  goto end;
> +switch (errorCode) {
> +case SA_AIS_OK:
> + break;
> +
> +/* LOGsv is busy. Put the notification to queue and re-send next time */
> +case SA_AIS_ERR_TRY_AGAIN:
> +case SA_AIS_ERR_TIMEOUT:
> + TRACE("Failed to log notification (ret: %d). Try next time.", 
> errorCode);
> + break;
> +
> +default:
> + osaf_abort(errorCode);
>  }
>}
>
> -end:
>TRACE_LEAVE();
> -
>return errorCode;
>  }
>
> diff --git a/tests/ntfsv/tet_longDnObject_notification.c 
> b/tests/ntfsv/tet_longDnObject_notification.c
> --- a/tests/ntfsv/tet_longDnObject_notification.c
> +++ b/tests/ntfsv/tet_longDnObject_notification.c
> @@ -19,6 +19,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include "tet_ntf.h"
>  #include "tet_ntf_common.h"
>  //#include "util.h"
> @@ -57,6 +58,166 @@ static SaNtfSecurityAlarmNotificationT m
>  extern void saAisNameLend(SaConstStringT value, SaNameT* name);
>  extern SaConstStringT saAisNameBorrow(const SaNameT* name);
>
> +//>
> +// For backup and restore IMM attribute values.
> +//<
> +
> +#define MAX_DATA 256
> +typedef struct {
> + char name[MAX_DATA];
> + char val[MAX_DATA];
> + int val_is_num;
> +} attrinfo_t;
> +
> +typedef struct {
> + attrinfo_t *attr;
> + size_t size;
> +} attrlist_t;
> +
> +typedef struct {
> + attrlist_t *alist;
> + char dn[MAX_DATA];
> +} imminfo_t;
> +
> +static void getVal(imminfo_t *info)
> +{
> + FILE *fp = NULL;
> + attrinfo_t *tmp = NULL;
> + char attrValue[MAX_DATA] = {0};
> + char command[MAX_DATA] = {0};
> + size_t s = info->alist->size;
> +
> + tmp = info->alist->attr;
> + while (s) {
> + sprintf(command, "immlist -a %s %s "
> + "| awk -F \"=\" '{print $2}' ", tmp->name,
> + info->dn);
> + fp = popen(command, 

[devel] [PATCH 0 of 1] Review Request for clm: fix string format for size_t type [#1906]

[Zoran Milinkovic]

Summary: clm: fix string format for size_t type [#1906]
Review request for Trac Ticket(s): 1906
Peer Reviewer(s): Mathi
Pull request to: Zoran
Affected branch(es): default(5.1)
Development branch: default(5.1)


Impacted area   Impact y/n

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


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

changeset 9a2b473cc2bc9ec744bd330a1b250f2b2a6688d0
Author: Zoran Milinkovic 
Date:   Tue, 16 Aug 2016 11:28:24 +0200

clm: fix string format for size_t type [#1906]

Fix string format for size_t type, so that 32-bit compilers can compile
OpenSAF without errors.


Complete diffstat:
--
 osaf/services/saf/clmsv/clms/clms_imm.c |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


Testing Commands:
-


Testing, Expected Results:
--
Compile OpenSAF with 32-bit compiler without errors.


Conditions of Submission:
-
Ack from Mathi


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


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


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

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

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

___ Your patches do not have proper short+long header

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

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

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

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

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

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

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

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

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

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

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

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

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

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

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

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

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

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


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

Re: [devel] [PATCH 1 of 1] clm: fix decoding for SaNameT type [#1906]

[A V Mahesh]

Hi Zoran,

ACK tested.

-AVM


On 8/16/2016 1:31 PM, Zoran Milinkovic wrote:
>   osaf/libs/common/clmsv/clmsv_enc_dec.c |  3 ++-
>   1 files changed, 2 insertions(+), 1 deletions(-)
>
>
> Add null-terminated string to the end of decoded string for SaNameT type.
>
> diff --git a/osaf/libs/common/clmsv/clmsv_enc_dec.c 
> b/osaf/libs/common/clmsv/clmsv_enc_dec.c
> --- a/osaf/libs/common/clmsv/clmsv_enc_dec.c
> +++ b/osaf/libs/common/clmsv/clmsv_enc_dec.c
> @@ -36,11 +36,12 @@ uint32_t clmsv_decodeSaNameT(NCS_UBAID *
>   osafassert(0);
>   }
>   if(length >= SA_MAX_NAME_LENGTH) {
> - value = (char *)calloc(1, length + 1);
> + value = (char *)malloc(length + 1);
>   }
>   ncs_dec_skip_space(uba, 2);
>   total_bytes += 2;
>   ncs_decode_n_octets_from_uba(uba, (uint8_t *)value, (uint32_t)length);
> + value[length] = 0;
>   osaf_extended_name_lend(value, name);
>   total_bytes += length;
>   return total_bytes;
>
> --
> ___
> 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] amfnd: avoid sending SUSI resp during recovery [#1931]

[Nagendra Kumar]

Please review it by today.

Thanks
-Nagu

> -Original Message-
> From: Nagendra Kumar
> Sent: 04 August 2016 10:51
> To: hans.nordeb...@ericsson.com; Praveen Malviya;
> minh.c...@dektech.com.au; gary@dektech.com.au
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [devel] [PATCH 1 of 1] amfnd: avoid sending SUSI resp during
> recovery [#1931]
> 
>  osaf/services/saf/amf/amfnd/susm.cc |  4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> 
> During component failover recovery (NPI SU), Amfnd attempt to send SUSI
> resp to Amfd though there is no SUSI assignment is undergoing.
> NPI SU terminating state is not a reflective of SUSI assignment rather it can
> be during recovery phases also.
> 
> diff --git a/osaf/services/saf/amf/amfnd/susm.cc
> b/osaf/services/saf/amf/amfnd/susm.cc
> --- a/osaf/services/saf/amf/amfnd/susm.cc
> +++ b/osaf/services/saf/amf/amfnd/susm.cc
> @@ -1832,7 +1832,9 @@ uint32_t avnd_su_pres_st_chng_prc(AVND_C
>   rc = avnd_di_oper_send(cb, su,
> SA_AMF_COMPONENT_FAILOVER);
> 
>   /* si assignment/removal failed.. inform AvD */
> - rc = avnd_di_susi_resp_send(cb, su,
> m_AVND_SU_IS_ALL_SI(su) ? 0 : si);
> + /* Send response to Amfd only when there is a
> pending assignment. */
> + if (m_AVND_SU_IS_ASSIGN_PEND(su))
> + rc = avnd_di_susi_resp_send(cb, su,
> m_AVND_SU_IS_ALL_SI(su) ? 0 :
> +si);
>   }
> 
>   /* instantiating -> term-failed */
> 
> --
> ___
> Opensaf-devel mailing list
> Opensaf-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/opensaf-devel

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

Re: [devel] [PATCH 1 of 5] amfd: replace SaNameT with string in include dir [#1642]

[praveen malviya]

On 15-Aug-16 5:05 PM, Long Nguyen wrote:

Hi Praveen,

Thanks for your suggestions.
Please see my comments marked with [Long[.

Best regards,
Long Nguyen.

On 8/12/2016 5:03 PM, praveen malviya wrote:



On 12-Aug-16 1:27 PM, Long Nguyen wrote:

Hi Praveen,

Actually, since Anders introduced the extended SaNameT in leap core, he
also added the osaf_extended_name_init() into leap.
Amf agent uses  leap library (i.e. saAmfInitialize()). So, applications
under amf control enabled long DN implicitly.
The SA_AIS_ERR_NAME_TOO_LONG return code is not returned in our case
(still SA_AIS_OK) due to the above reason. Consequently, the
applications are not crashed.

I am not sure if it is right to add osaf_extended_name_init() into leap.
However, it is the case now.


Addition of osaf_extended_name_init()  into leap is right because
every agent has to support long and short dn applications. But
osaf_extended_name_init() distinguish a long or short dn application
based on whether application has set "SA_ENABLE_EXTENDED_NAMES" or
not.If you see the implementation of this API, based on this exported
variable it remembers whether application is a long dn one or short dn
one. For this only only applications are recommended via documentation
to set this environment variable before calling any SAF API if they
want handle longdn.In this way when first SAF API is called (generally
sa,*>Initialize()), leap initialization will be done as a part of
agent creation. Inside leap init it will call
osaf_extended_name_init() which will use the environment variable to
remember about the nature of application.

The idea of CCB rejection was based on this only that an agent knows
via osaf_extended_* APIs that it is created by a longdn or shortdn
application. And this information can be passed to amfnd and hence to
AMFD.

But now what needs to be explored is why AMF Dispatch() is not
returning NAME_TOO_LONG when you have already coded for it? Since old
AMF demo has not enabled long dn, Dispatch() must return this error code.
Is there any problem with ava_sanamet_is_valid()?
Let us debug that.



Can you please share with us your ideas? Do we still need to truncate
long names in this case?

As we have discussed, rejection of CCB can be postponed as it requires
new messages or introduction of new fields in old messages, all the
way from AMFA to AMFD.
So we are left with three options:
1) Dispatch() will return NAME_TOO_LONG without invoking callback.
Current patch is doing this.
This has one disadvantage that comp/application may exit/crash.
2)Dispatch will return SA_AIS_OK "without" invoking the callback.
This will not confuse application.
There is one disadvantage here, AMF has an illegal COMPCSI.
3)Dispatch will return SA_AIS_OK "by" invoking the callback with
truncated values.
This has one advantage that AMF does not have illegal COMPCSI.
One disadvantage is that if comp is serving more CSI and then it
will not be able to rightly distinguish between the CSI names.

Option 2) sounds Ok to me as it will not create problems with
application as AMF is not invoking any callback and atleast
application is serving existing CSIs. Regarding the illegal COMPCSI in
AMF: A user can always delete it and deletion will not again result in
CSI remove callback because of the same reasons. At the same time we
are cautioning the user via documentation (REAMDME and PR doc).
[Long] I think the option 3 is better than the option 2. If we ignore
the callback, amf does not receive the responses from applications and
then applications get restarted due to callback timeout.

[Praveen] That was the problem with the current patch also, in which 
callback is not invoked and NAME_TOO_LONG is returned in dispatch(). So 
AMFND was already getting time out for the callback.


For option 2) there can be other consideration like generating fake 
Response() to AMFND or blocking the callback at AMFND itself (I was 
trying this blocking at amfnd approach crude patch in attachment. From 
agent to amfnd it is flat encode/decode advantage. But this needs to be 
explored further and will be complex. But it can act as first step 
towards CCB rejection.).
For option 3) how the truncation should be done to make it unique? Also 
there can still be one challenge: if a component on receiving this 
truncated CSI use it for PG tracking by calling the PG tracking API(with 
truncated CSI being an input param). So agent/amfnd will have to 
remember this reverse mapping between truncated CSI and actual CSI.


I think we can look for ideas from other services in which long dn 
support is there and similar situation was faced.


Thanks,
Praveen

thanks,
Praveen




Best regards,
Long Nguyen.

On 8/11/2016 3:04 PM, Long Nguyen wrote:

Hi Praveen,

Thanks for your suggestion.
In the situation you described below, you add a csi dynamically (long
DN) to an application (not support long DN).
So, we only need to truncate the csi name. This will help the
application not 

[devel] [PATCH 1 of 1] amfd: fix various CSI related problems [#1642]

[Gary Lee]

 osaf/services/saf/amf/amfd/csi.cc |  6 --
 osaf/services/saf/amf/amfd/csiattr.cc |  6 --
 2 files changed, 8 insertions(+), 4 deletions(-)


This fixes various CSI related problems reported by Praveen in
https://sourceforge.net/p/opensaf/tickets/1642/#5579

Credit: Praveen

diff --git a/osaf/services/saf/amf/amfd/csi.cc 
b/osaf/services/saf/amf/amfd/csi.cc
--- a/osaf/services/saf/amf/amfd/csi.cc
+++ b/osaf/services/saf/amf/amfd/csi.cc
@@ -618,7 +618,7 @@ static SaAisErrorT csi_ccb_completed_mod
goto done;

}
-const std::string required_dn(Amf::to_string(static_cast(attr_mod->modAttr.attrValues[0])));
+   const std::string 
required_dn(Amf::to_string(static_cast(attr_mod->modAttr.attrValues[0])));
const AVD_CSI *required_csi = csi_db->find(required_dn);
 
// Required CSI must exist in current model
@@ -629,7 +629,9 @@ static SaAisErrorT csi_ccb_completed_mod
}
 
// Required CSI must be contained in the same SI
-   if (object_name.find(required_dn) == std::string::npos) 
{
+   std::string si_name;
+   avsv_sanamet_init(required_dn, si_name, "safSi");
+   if (object_name.find(si_name) == std::string::npos) {
report_ccb_validation_error(opdata,
"'%s' is not in the same SI as 
'%s'",
object_name.c_str(), 
required_dn.c_str());
diff --git a/osaf/services/saf/amf/amfd/csiattr.cc 
b/osaf/services/saf/amf/amfd/csiattr.cc
--- a/osaf/services/saf/amf/amfd/csiattr.cc
+++ b/osaf/services/saf/amf/amfd/csiattr.cc
@@ -156,12 +156,13 @@ static AVD_CSI_ATTR *csi_name_value_pair
  **/
 static AVD_CSI_ATTR * csi_name_value_pair_find(const AVD_CSI *csi, const 
std::string& csiattr_name, const char *value)
 {
-AVD_CSI_ATTR *i_attr = csi->list_attributes;
+   AVD_CSI_ATTR *i_attr = csi->list_attributes;
TRACE_ENTER();
 
 while (i_attr != nullptr) {
if 
((csiattr_name.compare(Amf::to_string(_attr->name_value.name)) == 0) &&
(strncmp((char *)i_attr->name_value.string_ptr, 
value, strlen(value)) == 0)) {
+   TRACE_LEAVE();
return i_attr;
}
 i_attr = i_attr->attr_next;
@@ -182,6 +183,7 @@ static AVD_CSI_ATTR * is_csiattr_exists(
 
while (i_attr != nullptr) {
if (dn.compare(Amf::to_string(_attr->name_value.name)) == 0) {
+   TRACE_LEAVE();
return i_attr;
}
i_attr = i_attr->attr_next;
@@ -534,7 +536,7 @@ static void csiattr_modify_apply(CcbUtil
i_attr->attr_next = csiattr;
csiattr = i_attr;
 
-   
osaf_extended_name_alloc(csi_attr_name.c_str(), >name_value.value);
+   
osaf_extended_name_alloc(csi_attr_name.c_str(), >name_value.name);
csiattr->name_value.string_ptr = new 
char[strlen(value)+1]();
memcpy(csiattr->name_value.string_ptr, 
value, strlen(value)+1 );
} /* for  */

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

[devel] [PATCH 0 of 1] Review Request for amfd: fix various CSI related problems [#1642]

[Gary Lee]

Summary: amfd: fix various CSI related problems [#1642] 
Review request for Trac Ticket(s): 1642 
Peer Reviewer(s): AMF devs 
Pull request to: <>
Affected branch(es): default 
Development branch: default 


Impacted area   Impact y/n

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


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

changeset 537536bb6d8098a7f77e508e3cfd8e068d26c511
Author: Gary Lee 
Date:   Tue, 16 Aug 2016 18:15:58 +1000

amfd: fix various CSI related problems [#1642]

This fixes various CSI related problems reported by Praveen in
https://sourceforge.net/p/opensaf/tickets/1642/#5579

Credit: Praveen


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


Testing Commands:
-
See https://sourceforge.net/p/opensaf/tickets/1642/#5579

Testing, Expected Results:
--
 <>


Conditions of Submission:
-
 <>


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


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


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

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

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

___ Your patches do not have proper short+long header

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

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

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

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

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

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

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

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

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

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

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

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

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

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

___ You have a misconfigured ~/.hgrc file (i.e. username, email etc)

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

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

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


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

Re: [devel] [PATCH 1 of 1] cpsv: To update checkpoint user number for each node [#1669] V4

[A V Mahesh]

This patch still has the problem

Bring SC-2 as standby ( With this patch ) & Brint SC-1 Active ( With out 
this patch )

And run following test case on SC-2( With this patch node )

1) Init with general callback
2) Asynchrously opened ckpt



SC-1:/var/crash/opensaf # Aug 16 13:38:41 SC-1 osafimmnd[3583]: NO 
Implementer (applier) connected: 16 (@safAmfService2010f) <126, 2010f>
Aug 16 13:38:42 SC-1 osafimmnd[3583]: NO Implementer (applier) 
connected: 17 (@OpenSafImmReplicatorB) <170, 2010f>
Aug 16 13:38:42 SC-1 osafntfimcnd[3789]: NO Started
Aug 16 13:38:44 SC-1 osafamfd[3623]: NO Cold sync complete!
Aug 16 13:39:10 SC-1 osafimmnd[3583]: NO Ccb 2 COMMITTED (immcfg_PL-4_9452)
Aug 16 13:39:10 SC-1 osafimmnd[3583]: NO Ccb 3 COMMITTED (safImmService)
Aug 16 13:39:12 SC-1 sudo:  tet : TTY=unknown ; PWD=/tmp/03805aa ; 
USER=root ; COMMAND=/usr/bin/pkill -u root -P 1 mqsv_a
Aug 16 13:39:12 SC-1 osafckptd[3659]: hj_enc.c:311: 
decode_flatten_space: Assertion 'p8' failed.
Aug 16 13:39:12 SC-1 osafamfnd[3633]: NO 
'safComp=CPD,safSu=SC-1,safSg=2N,safApp=OpenSAF' faulted due to 
'avaDown' : Recovery is 'nodeFailfast'
Aug 16 13:39:12 SC-1 osafamfnd[3633]: ER 
safComp=CPD,safSu=SC-1,safSg=2N,safApp=OpenSAF Faulted due to:avaDown 
Recovery is:nodeFailfast
Aug 16 13:39:12 SC-1 osafamfnd[3633]: Rebooting OpenSAF NodeId = 131343 
EE Name = , Reason: Component faulted: recovery is node failfast, 
OwnNodeId = 131343, SupervisionTime = 60
Aug 16 13:39:12 SC-1 opensaf_reboot: Rebooting local node; timeout=60
Aug 16 13:39:13 SC-1 sudo:  tet : TTY=unknown ; PWD=/tmp/03805aa ; 
USER=root ; COMMA

=

-AVM

On 8/12/2016 11:41 AM, Vo Minh Hoang wrote:
> Dear Mahesh,
>
> Thank you very much for your help.
> I send the attached patch that fix missing in encode/decode function.
>
> Thank you and best regards,
> Hoang
>
> -Original Message-
> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
> Sent: Friday, August 12, 2016 10:15 AM
> To: Vo Minh Hoang 
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 1 of 1] cpsv: To update checkpoint user number for each
> node [#1669] V4
>
> I will test for you send the patch.
>
> -AVM
>
>
> On 8/11/2016 3:38 PM, Vo Minh Hoang wrote:
>> Dear Mahesh,
>>
>> Would you please tell me the case that produce this error?
>> I review source code and found that encode/decode function missed 1
>> attribute.
>> But running test in our environment could not reproduce this problem.
>>
>> Thank you and best regards,
>> Hoang
>>
>> -Original Message-
>> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
>> Sent: Tuesday, August 9, 2016 4:35 PM
>> To: Hoang Vo 
>> Cc: opensaf-devel@lists.sourceforge.net
>> Subject: Re: [PATCH 1 of 1] cpsv: To update checkpoint user number for
>> each node [#1669] V4
>>
>> Hi Hoang ,
>>
>> Please hold on pushing.
>>
>> On new node we have see some issue please check CPD enode and decode
>> once ( new patch node ) .
>>
>> Aug  9 14:23:01 SC-1 osafckptd[20478]: hj_enc.c:311:
>> decode_flatten_space: Assertion 'p8' failed.
>> Aug  9 14:23:01 SC-1 osafamfnd[20439]: NO
>> 'safComp=CPD,safSu=SC-1,safSg=2N,safApp=OpenSAF' faulted due to 'avaDown'
> :
>> Recovery is 'nodeFailfast'
>>
>> -AVM
>>
>>
>>
>> On 8/9/2016 2:09 PM, A V Mahesh wrote:
>>> ACK,
>>>
>>> -AVM
>>>
>>>
>>> On 8/3/2016 4:02 PM, Hoang Vo wrote:
 osaf/libs/common/cpsv/include/cpd_cb.h |2 +
 osaf/libs/common/cpsv/include/cpd_proc.h |3 +
 osaf/libs/common/cpsv/include/cpd_red.h  |   13 ++
 osaf/libs/common/cpsv/include/cpsv_evt.h |8 +
 osaf/services/saf/cpsv/cpd/cpd_db.c  |   14 ++-
 osaf/services/saf/cpsv/cpd/cpd_evt.c |8 +
 osaf/services/saf/cpsv/cpd/cpd_mbcsv.c   |   96 ---
 osaf/services/saf/cpsv/cpd/cpd_proc.c|  148
 +++
 osaf/services/saf/cpsv/cpd/cpd_red.c |   30 -
 osaf/services/saf/cpsv/cpd/cpd_sbevt.c   |   57 +--
 10 files changed, 344 insertions(+), 35 deletions(-)


 Problem:
 ---
 The saCkptCheckpointNumOpeners is not updated when a node which has
 a checkpoint client restarts.

 Solution:
 
 Currently CPD doesn't store number of user on each node. This patch
 updates CPD to update information about users on each node for each
 checkpoint. When a node restarts, the CPD update the total number of
 users for a checkpoint accordingly. This is reflected on
 saCkptCheckpointNumOpeners attribute correctly.

 diff --git a/osaf/libs/common/cpsv/include/cpd_cb.h
 b/osaf/libs/common/cpsv/include/cpd_cb.h
 --- a/osaf/libs/common/cpsv/include/cpd_cb.h
 +++ 

Re: [devel] [PATCH 3 of 5] imm: Checking of Imm limits [#195]

[Zoran Milinkovic]

Hi Neelakanta,

Ack on all patches.
No need for sending the code on another review. They are all minor changes 
mostly related on code-style, and not on functionality.

Thanks,
Zoran

-Original Message-
From: Neelakanta Reddy [mailto:reddy.neelaka...@oracle.com] 
Sent: den 16 augusti 2016 10:07
To: Zoran Milinkovic; Hung Duc Nguyen
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 3 of 5] imm: Checking of Imm limits [#195]

Hi Zoran,

All the attribute definition will be moved to the top of the file.
The response for the remaining comments.

Thanks,
Neel.

On 2016/08/12 07:36 PM, Zoran Milinkovic wrote:
> Hi Neelakanta,
>
> Find my comments inline
>
> -Original Message-
> From: reddy.neelaka...@oracle.com [mailto:reddy.neelaka...@oracle.com]
> Sent: den 27 juli 2016 10:32
> To: Zoran Milinkovic; Hung Duc Nguyen
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 3 of 5] imm: Checking of Imm limits [#195]
>
>   osaf/services/saf/immsv/immnd/ImmModel.cc |  322 
> +-
>   osaf/services/saf/immsv/immnd/ImmModel.hh |5 +-
>   2 files changed, 324 insertions(+), 3 deletions(-)
>
>
> diff --git a/osaf/services/saf/immsv/immnd/ImmModel.cc 
> b/osaf/services/saf/immsv/immnd/ImmModel.cc
> --- a/osaf/services/saf/immsv/immnd/ImmModel.cc
> +++ b/osaf/services/saf/immsv/immnd/ImmModel.cc
> @@ -1154,6 +1154,13 @@ immModel_protocol50Allowed(IMMND_CB *cb)
>   SA_TRUE : SA_FALSE;
>   }
>   
> +SaBoolT
> +immModel_protocol51Allowed(IMMND_CB *cb) {
> +return (ImmModel::instance(>immModel)->protocol51Allowed()) ?
> +SA_TRUE : SA_FALSE;
> +}
> +
>   OsafImmAccessControlModeT
>   immModel_accessControlMode(IMMND_CB *cb)
>   {
> @@ -3271,6 +3278,21 @@ ImmModel::classCreate(const ImmsvOmClass
>   return SA_AIS_ERR_INVALID_PARAM;
>   }
>   
> +ObjectMap::iterator oit = sObjectMap.find(immObjectDn);
> +if(protocol51Allowed() && oit != sObjectMap.end() && !isLoading ){
> +std::string immMaxClasses(OPENSAF_IMMSV_MAX_CLASSES);
> +ObjectInfo* immObject =  oit->second;
> +ImmAttrValueMap::iterator avi = 
> immObject->mAttrValueMap.find(immMaxClasses);
> +osafassert(avi != immObject->mAttrValueMap.end());
> +osafassert(!(avi->second->isMultiValued()));
> +ImmAttrValue* valuep = avi->second;
> +unsigned int maxClasses = valuep->getValue_int();
> +if( sClassMap.size() >= maxClasses){
> +LOG_NO("ERR_NO_RESOURCES: maximum class limit %d has been reched 
> for the cluster",
> +  maxClasses);
> +return SA_AIS_ERR_NO_RESOURCES;
> +}
> +}
>
> [Zoran] "std::string immMaxClasses(OPENSAF_IMMSV_MAX_CLASSES);" can be moved 
> to the top of the file with other definition of strings.
> I would create a common method for finding max number of classes and use it 
> in the block above. The code is not wrong. I'll leave it to you if you want 
> to create a common method.
>
>   ClassMap::iterator i = sClassMap.find(className);
>   if (i == sClassMap.end()) {
>   /* Class-name is unique case-sensitive.
> @@ -3597,6 +3619,8 @@ ImmModel::classCreate(const ImmsvOmClass
>   }
>   }
>   
> +
> +
>   if(illegal) {
>   if(err == SA_AIS_OK) {
>   LOG_NO("ERR_INVALID_PARAM: Problem with new class '%s'", 
> className.c_str()); @@ -3966,6 +3990,34 @@ ImmModel::protocol50Allowed()
>   return noStdFlags & OPENSAF_IMM_FLAG_PRT50_ALLOW;
>   }
>   
> +
> +bool
> +ImmModel::protocol51Allowed()
> +{
> +//TRACE_ENTER();
> +/* Assume that all nodes are running the same version when loading */
> +if (sImmNodeState == IMM_NODE_LOADING) {
> +return true;
> +}
> +ObjectMap::iterator oi = sObjectMap.find(immObjectDn);
> +if(oi == sObjectMap.end()) {
> +TRACE_LEAVE();
> +return false;
> +}
> +
> +ObjectInfo* immObject =  oi->second;
> +ImmAttrValueMap::iterator avi =
> +immObject->mAttrValueMap.find(immAttrNostFlags);
> +osafassert(avi != immObject->mAttrValueMap.end());
> +osafassert(!(avi->second->isMultiValued()));
> +ImmAttrValue* valuep = avi->second;
> +unsigned int noStdFlags = valuep->getValue_int();
> +
> +//TRACE_LEAVE();
> +return noStdFlags & OPENSAF_IMM_FLAG_PRT51_ALLOW; }
> +
> +
>   bool
>   ImmModel::protocol41Allowed()
>   {
> @@ -4114,6 +4166,44 @@ ImmModel::verifySchemaChange(const std::
>   verifyFailed = notCompatibleAtt(className, newClassInfo, 
> attName, NULL, newAttr, NULL) ||
>   verifyFailed;
>   newAttrs[inew->first] = newAttr;
> +if(!verifyFailed && (className == immClassName)){
> +unsigned int val;
> +if ( attName == OPENSAF_IMMSV_MAX_CLASSES) {
>
> [Zoran] Same as in earlier comment. Create a string for 
> OPENSAF_IMMSV_MAX_CLASSES in the top of the file with strings for other 
> attributes.
>
> + 

Re: [devel] [PATCH 3 of 5] imm: Checking of Imm limits [#195]

[Neelakanta Reddy]

Hi Zoran,

All the attribute definition will be moved to the top of the file.
The response for the remaining comments.

Thanks,
Neel.

On 2016/08/12 07:36 PM, Zoran Milinkovic wrote:
> Hi Neelakanta,
>
> Find my comments inline
>
> -Original Message-
> From: reddy.neelaka...@oracle.com [mailto:reddy.neelaka...@oracle.com]
> Sent: den 27 juli 2016 10:32
> To: Zoran Milinkovic; Hung Duc Nguyen
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 3 of 5] imm: Checking of Imm limits [#195]
>
>   osaf/services/saf/immsv/immnd/ImmModel.cc |  322 
> +-
>   osaf/services/saf/immsv/immnd/ImmModel.hh |5 +-
>   2 files changed, 324 insertions(+), 3 deletions(-)
>
>
> diff --git a/osaf/services/saf/immsv/immnd/ImmModel.cc 
> b/osaf/services/saf/immsv/immnd/ImmModel.cc
> --- a/osaf/services/saf/immsv/immnd/ImmModel.cc
> +++ b/osaf/services/saf/immsv/immnd/ImmModel.cc
> @@ -1154,6 +1154,13 @@ immModel_protocol50Allowed(IMMND_CB *cb)
>   SA_TRUE : SA_FALSE;
>   }
>   
> +SaBoolT
> +immModel_protocol51Allowed(IMMND_CB *cb)
> +{
> +return (ImmModel::instance(>immModel)->protocol51Allowed()) ?
> +SA_TRUE : SA_FALSE;
> +}
> +
>   OsafImmAccessControlModeT
>   immModel_accessControlMode(IMMND_CB *cb)
>   {
> @@ -3271,6 +3278,21 @@ ImmModel::classCreate(const ImmsvOmClass
>   return SA_AIS_ERR_INVALID_PARAM;
>   }
>   
> +ObjectMap::iterator oit = sObjectMap.find(immObjectDn);
> +if(protocol51Allowed() && oit != sObjectMap.end() && !isLoading ){
> +std::string immMaxClasses(OPENSAF_IMMSV_MAX_CLASSES);
> +ObjectInfo* immObject =  oit->second;
> +ImmAttrValueMap::iterator avi = 
> immObject->mAttrValueMap.find(immMaxClasses);
> +osafassert(avi != immObject->mAttrValueMap.end());
> +osafassert(!(avi->second->isMultiValued()));
> +ImmAttrValue* valuep = avi->second;
> +unsigned int maxClasses = valuep->getValue_int();
> +if( sClassMap.size() >= maxClasses){
> +LOG_NO("ERR_NO_RESOURCES: maximum class limit %d has been reched 
> for the cluster",
> +  maxClasses);
> +return SA_AIS_ERR_NO_RESOURCES;
> +}
> +}
>
> [Zoran] "std::string immMaxClasses(OPENSAF_IMMSV_MAX_CLASSES);" can be moved 
> to the top of the file with other definition of strings.
> I would create a common method for finding max number of classes and use it 
> in the block above. The code is not wrong. I'll leave it to you if you want 
> to create a common method.
>
>   ClassMap::iterator i = sClassMap.find(className);
>   if (i == sClassMap.end()) {
>   /* Class-name is unique case-sensitive.
> @@ -3597,6 +3619,8 @@ ImmModel::classCreate(const ImmsvOmClass
>   }
>   }
>   
> +
> +
>   if(illegal) {
>   if(err == SA_AIS_OK) {
>   LOG_NO("ERR_INVALID_PARAM: Problem with new class '%s'", 
> className.c_str());
> @@ -3966,6 +3990,34 @@ ImmModel::protocol50Allowed()
>   return noStdFlags & OPENSAF_IMM_FLAG_PRT50_ALLOW;
>   }
>   
> +
> +bool
> +ImmModel::protocol51Allowed()
> +{
> +//TRACE_ENTER();
> +/* Assume that all nodes are running the same version when loading */
> +if (sImmNodeState == IMM_NODE_LOADING) {
> +return true;
> +}
> +ObjectMap::iterator oi = sObjectMap.find(immObjectDn);
> +if(oi == sObjectMap.end()) {
> +TRACE_LEAVE();
> +return false;
> +}
> +
> +ObjectInfo* immObject =  oi->second;
> +ImmAttrValueMap::iterator avi =
> +immObject->mAttrValueMap.find(immAttrNostFlags);
> +osafassert(avi != immObject->mAttrValueMap.end());
> +osafassert(!(avi->second->isMultiValued()));
> +ImmAttrValue* valuep = avi->second;
> +unsigned int noStdFlags = valuep->getValue_int();
> +
> +//TRACE_LEAVE();
> +return noStdFlags & OPENSAF_IMM_FLAG_PRT51_ALLOW;
> +}
> +
> +
>   bool
>   ImmModel::protocol41Allowed()
>   {
> @@ -4114,6 +4166,44 @@ ImmModel::verifySchemaChange(const std::
>   verifyFailed = notCompatibleAtt(className, newClassInfo, 
> attName, NULL, newAttr, NULL) ||
>   verifyFailed;
>   newAttrs[inew->first] = newAttr;
> +if(!verifyFailed && (className == immClassName)){
> +unsigned int val;
> +if ( attName == OPENSAF_IMMSV_MAX_CLASSES) {
>
> [Zoran] Same as in earlier comment. Create a string for 
> OPENSAF_IMMSV_MAX_CLASSES in the top of the file with strings for other 
> attributes.
>
> +val = newAttr->mDefaultValue.getValue_int();
> +if( sClassMap.size() > val){
> +LOG_NO("The Number of classes in the cluster %lu 
> greater than the schema change"
> + "value %d", sClassMap.size(), val);
> +verifyFailed = true;
> + }
> +}
> +
> +if ( !verifyFailed && 

Re: [devel] osafclmna[5375]: ER Exiting

[Zoran Milinkovic]

Hi Mathi,

I just sent the fix to the review.

Thanks,
Zoran

-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com] 
Sent: den 16 augusti 2016 08:37
To: Zoran Milinkovic
Cc: opensaf-devel@lists.sourceforge.net
Subject: osafclmna[5375]: ER Exiting

Hi Zoran Milinkovic,

It seems some problem with thees patches :

Opensaf is not comingup with error  `SC-2 osafclmna[5375]: ER*SC-2m* is not a 
configured node` & ` SC-2 osafclmna[5375]: ER Exiting`

=
changeset:   7855:bc669776cf7f
tag: tip
user:Zoran Milinkovic 
date:Mon Aug 15 09:38:00 2016 +0530
summary: clm: add support for long RDN [#1906]

changeset:   7854:e9a1f9f7e1fb
parent:  7851:6ba070e84429
user:Zoran Milinkovic 
date:Mon Aug 15 09:22:54 2016 +0530
summary: clm: fix return error codes in IMM callbacks [#1917]

changeset:   7853:b0aa865e70df
branch:  opensaf-5.0.x
parent:  7844:c603424ffe8d
user:Zoran Milinkovic 
date:Mon Aug 15 09:22:54 2016 +0530
summary: clm: fix return error codes in IMM callbacks [#1917]


=


Configured Opensaf as follws :

  ./bootstrap.sh ;./configure --enable-imm-pbe --enable-tests --enable-tipc 
--enable-ntf-imcn



Aug 16 12:00:09 SC-2 osafntfimcnd[5448]: NO Started
Aug 16 12:00:09 SC-2 osafclmd[5455]: Started
Aug 16 12:00:09 SC-2 osafimmnd[5414]: NO Implementer connected: 4 
(safClmService) <21, 2020f>
Aug 16 12:00:09 SC-2 osafimmnd[5414]: NO implementer for class 
'SaClmNode' is safClmService => class extent is safe.
Aug 16 12:00:09 SC-2 osafimmnd[5414]: NO implementer for class 
'SaClmCluster' is safClmService => class extent is safe.
Aug 16 12:00:09 SC-2 osafclmd[5455]: NO Node 'SC-2m' requests to join 
the cluster but is unconfigured
Aug 16 12:00:09 SC-2 osafclmna[5375]: ER SC-2m is not a configured node
Aug 16 12:00:09 SC-2 osafclmna[5375]: ER Exiting
Aug 16 12:00:10 SC-2 osafamfd[5465]: Started
Aug 16 12:00:10 SC-2 osafimmnd[5414]: NO Implementer connected: 5 
(safAmfService) <26, 2020f>
Aug 16 12:00:10 SC-2 osafimmnd[5414]: NO implementer for class 
'SaAmfCompBaseType' is safAmfService => class extent is safe.
Aug 16 12:00:10 SC-2 osafimmnd[5414]: NO implementer for class 
'SaAmfSUBaseType' is safAmfServ

-AVM
--
___
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 clm: fix decoding for SaNameT type [#1906]

[Zoran Milinkovic]

Summary: clm: fix decoding for SaNameT type [#1906]
Review request for Trac Ticket(s): 1906
Peer Reviewer(s): Mathi
Pull request to: Zoran
Affected branch(es): default(5.1)
Development branch: default(5.1)


Impacted area   Impact y/n

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


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

changeset 441e348fe941b66019c49c31d0e4bd73efd8d094
Author: Zoran Milinkovic 
Date:   Tue, 16 Aug 2016 09:57:11 +0200

clm: fix decoding for SaNameT type [#1906]

Add null-terminated string to the end of decoded string for SaNameT 
type.


Complete diffstat:
--
 osaf/libs/common/clmsv/clmsv_enc_dec.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


Testing Commands:
-


Testing, Expected Results:
--
OpenSAF should be able to start


Conditions of Submission:
-
Ack from Mathi


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

[devel] [PATCH 1 of 1] clm: fix decoding for SaNameT type [#1906]

[Zoran Milinkovic]

 osaf/libs/common/clmsv/clmsv_enc_dec.c |  3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)


Add null-terminated string to the end of decoded string for SaNameT type.

diff --git a/osaf/libs/common/clmsv/clmsv_enc_dec.c 
b/osaf/libs/common/clmsv/clmsv_enc_dec.c
--- a/osaf/libs/common/clmsv/clmsv_enc_dec.c
+++ b/osaf/libs/common/clmsv/clmsv_enc_dec.c
@@ -36,11 +36,12 @@ uint32_t clmsv_decodeSaNameT(NCS_UBAID *
osafassert(0);
}
if(length >= SA_MAX_NAME_LENGTH) {
-   value = (char *)calloc(1, length + 1);
+   value = (char *)malloc(length + 1);
}
ncs_dec_skip_space(uba, 2);
total_bytes += 2;
ncs_decode_n_octets_from_uba(uba, (uint8_t *)value, (uint32_t)length);
+   value[length] = 0;
osaf_extended_name_lend(value, name);
total_bytes += length;
return total_bytes;

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

Re: [devel] [PATCH 1 of 1] cpd: handle BAD_HANDLE from saClmDispatch [#1822]

[A V Mahesh]

Hi Hoang,

ACK tested with normal configuration .

Note : not created error  SA_AIS_ERR_BAD_HANDLE.

-AVM


On 8/16/2016 12:15 PM, Hoang Vo wrote:
>   osaf/services/saf/cpsv/cpd/cpd_init.c |  67 
> ++-
>   1 files changed, 66 insertions(+), 1 deletions(-)
>
>
> Problem:
> ---
> cpd doesn't seem to currently recover from BAD_HANDLE when calling 
> saClmDispatch()
> This is important if a node is promoted to a controller.
>
> Solution:
> 
> Re-initialize CLM HANDLE
>
> diff --git a/osaf/services/saf/cpsv/cpd/cpd_init.c 
> b/osaf/services/saf/cpsv/cpd/cpd_init.c
> --- a/osaf/services/saf/cpsv/cpd/cpd_init.c
> +++ b/osaf/services/saf/cpsv/cpd/cpd_init.c
> @@ -61,6 +61,8 @@ static uint32_t cpd_lib_destroy(CPD_DEST
>   
>   static bool cpd_clear_mbx(NCSCONTEXT arg, NCSCONTEXT msg);
>   
> +static SaAisErrorT cpd_clm_init_bg(CPD_CB *cb);
> +
>   void cpd_main_process(CPD_CB *cb);
>   
>   
> /
> @@ -200,6 +202,63 @@ done:
>   }
>   
>   
> /
> + * Name  : cpd_clm_init_thread
> + *
> + * Description   : This function is thread function to initialize clm
> + *
> + * Arguments : -
> + *
> + * Return Values : -
> + *
> + * Notes : None.
> + 
> */
> +static void* cpd_clm_init_thread(void* arg)
> +{
> + CPD_CB *cb = (CPD_CB*)arg;
> +
> + TRACE_ENTER();
> +
> + SaAisErrorT rc = cpd_clm_init(cb);
> + if (rc != SA_AIS_OK) {
> + exit(EXIT_FAILURE);
> + }
> +
> + /* Notify main process to update clm select object */
> + ncs_sel_obj_ind((NCS_SEL_OBJ*)>clm_sel_obj);
> +
> + TRACE_LEAVE();
> + return NULL;
> +}
> +
> +/
> + * Name  : cpd_clm_init_bg
> + *
> + * Description   : This function is to start initialize clm thread
> + *
> + * Arguments : -
> + *
> + * Return Values : -
> + *
> + * Notes : None.
> + 
> */
> +static SaAisErrorT cpd_clm_init_bg(CPD_CB *cb)
> +{
> + pthread_t thread;
> + pthread_attr_t attr;
> + pthread_attr_init();
> + pthread_attr_setdetachstate(, PTHREAD_CREATE_DETACHED);
> +
> + if (pthread_create(, , cpd_clm_init_thread, cb) != 0) {
> + LOG_ER("pthread_create FAILED: %s", strerror(errno));
> + exit(EXIT_FAILURE);
> + }
> +
> + pthread_attr_destroy();
> +
> + return SA_AIS_OK;
> +}
> +
> +/
>* Name  : cpd_lib_init
>*
>* Description   : This is the function which initalize the CPD libarary.
> @@ -572,7 +631,13 @@ void cpd_main_process(CPD_CB *cb)
>   if (fds[FD_CLM].revents & POLLIN) {
>   /* dispatch all the CLM pending function */
>   error = saClmDispatch(cb->clm_hdl, SA_DISPATCH_ALL);
> - if (error != SA_AIS_OK) {
> + if (error == SA_AIS_ERR_BAD_HANDLE) {
> + LOG_NO("Bad CLM handle. Reinitializing.");
> + osaf_nanosleep();
> + cpd_clm_init_bg(cb);
> + /* Ignore the FD_CLM */
> + fds[FD_CLM].fd = -1;
> + } else if (error != SA_AIS_OK) {
>   LOG_ER("saClmDispatch failed: %u", error);
>   }
>   }


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

Re: [devel] [PATCH 1 of 5] imm: Remove the IMM limits checking in encoding and decoding [#195]

[Neelakanta Reddy]

Hi Zoran,

will change OPENSAF_IMMSV_* to OPENSAF_IMM_* while pushing.

Thanks,
Neel.

On 2016/08/12 07:35 PM, Zoran Milinkovic wrote:
> Hi Neelakanta,
>
> In the bottom of the patch is next change:
> +#define OPENSAF_IMMSV_MAX_CLASSES "maxClasses"
> +#define OPENSAF_IMMSV_MAX_IMPLEMENTERS "maxImplementers"
> +#define OPENSAF_IMMSV_MAX_ADMINOWNERS "maxAdminowners"
> +#define OPENSAF_IMMSV_MAX_CCBS "maxCcbs"
>
> Why define OPENSAF_IMMSV_* for new attribute names instead of OPENSAF_IMM_* 
> as all other attribute names are defined ?
>
> Thanks,
> Zoran
>
> -Original Message-
> From: reddy.neelaka...@oracle.com [mailto:reddy.neelaka...@oracle.com]
> Sent: den 27 juli 2016 10:32
> To: Zoran Milinkovic; Hung Duc Nguyen
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 1 of 5] imm: Remove the IMM limits checking in encoding and 
> decoding [#195]
>
>   osaf/libs/common/immsv/immsv_evt.c |  69 
> +++--
>   osaf/libs/common/immsv/include/immsv_api.h |   9 +++
>   2 files changed, 18 insertions(+), 60 deletions(-)
>
>
> diff --git a/osaf/libs/common/immsv/immsv_evt.c 
> b/osaf/libs/common/immsv/immsv_evt.c
> --- a/osaf/libs/common/immsv/immsv_evt.c
> +++ b/osaf/libs/common/immsv/immsv_evt.c
> @@ -30,11 +30,6 @@
>   #include "osaf_extended_name.h"
>   #include "saAis.h"
>   
> -#define IMMSV_MAX_CLASSES 1000
> -#define IMMSV_MAX_IMPLEMENTERS 3000
> -#define IMMSV_MAX_ADMINOWNERS 2000
> -#define IMMSV_MAX_CCBS 1
> -
>   #define IMMSV_RSRV_SPACE_ASSERT(P,B,S) 
> P=ncs_enc_reserve_space(B,S);osafassert(P)
>   #define IMMSV_FLTN_SPACE_ASSERT(P,M,B,S) 
> P=ncs_dec_flatten_space(B,M,S);osafassert(P)
>   
> @@ -820,7 +815,6 @@ static void immsv_evt_enc_class(NCS_UBAI
>   
>   static uint32_t immsv_evt_dec_class(NCS_UBAID *i_ub, IMMSV_CLASS_LIST **r)
>   {
> - int depth = 1;
>   uint8_t c8;
>   
>   do {
> @@ -850,13 +844,7 @@ static uint32_t immsv_evt_dec_class(NCS_
>   ncs_dec_skip_space(i_ub, 1);
>   
>   r = &((*r)->next);
> - ++depth;
> - } while (c8 && (depth < IMMSV_MAX_CLASSES));
> -
> - if (depth >= IMMSV_MAX_CLASSES) {
> - LOG_ER("TOO MANY classes line: %u", __LINE__);
> - return NCSCC_RC_OUT_OF_MEM;
> - }
> + } while (c8);
>   
>   return NCSCC_RC_SUCCESS;
>   }
> @@ -918,7 +906,6 @@ static void immsv_evt_enc_impl(NCS_UBAID
>   
>   static uint32_t immsv_evt_dec_impl(NCS_UBAID *i_ub, IMMSV_IMPL_LIST **q)
>   {
> - int depth = 1;
>   uint8_t c8;
>   
>   do {
> @@ -950,13 +937,7 @@ static uint32_t immsv_evt_dec_impl(NCS_U
>   ncs_dec_skip_space(i_ub, 1);
>   
>   q = &((*q)->next);
> - ++depth;
> - } while (c8 && (depth < IMMSV_MAX_IMPLEMENTERS));
> -
> - if (depth >= IMMSV_MAX_IMPLEMENTERS) {
> - LOG_ER("TOO MANY implementers line:%u", __LINE__);
> - return NCSCC_RC_OUT_OF_MEM;
> - }
> + } while (c8);
>   
>   return NCSCC_RC_SUCCESS;
>   }
> @@ -1015,7 +996,6 @@ static uint32_t immsv_evt_enc_admo(NCS_U
>   
>   static uint32_t immsv_evt_dec_admo(NCS_UBAID *i_ub, IMMSV_ADMO_LIST **p)
>   {
> - int depth = 1;
>   uint8_t c8;
>   
>   do {
> @@ -1052,13 +1032,7 @@ static uint32_t immsv_evt_dec_admo(NCS_U
>   ncs_dec_skip_space(i_ub, 1);
>   
>   p = &((*p)->next);
> - ++depth;
> - } while (c8 && (depth < IMMSV_MAX_ADMINOWNERS));
> -
> - if (depth >= IMMSV_MAX_ADMINOWNERS) {
> - LOG_ER("TOO MANY Admin Owners");
> - return NCSCC_RC_OUT_OF_MEM;
> - }
> + } while (c8 );
>   
>   return NCSCC_RC_SUCCESS;
>   }
> @@ -1791,61 +1765,38 @@ static uint32_t immsv_evt_enc_sublevels(
>   return immsv_evt_enc_name_list(o_ub, 
> i_evt->info.immnd.info.admReq.objectNames);
>   } else if ((i_evt->info.immnd.type == 
> IMMND_EVT_ND2ND_SYNC_FINALIZE) ||
>   (i_evt->info.immnd.type == 
> IMMND_EVT_ND2ND_SYNC_FINALIZE_2)) {
> - int depth = 0;
>   uint8_t *p8;
>   
>   IMMSV_ADMO_LIST *p = 
> i_evt->info.immnd.info.finSync.adminOwners;
> - while (p && (depth < IMMSV_MAX_ADMINOWNERS)) {
> + while (p ) {
>   if (immsv_evt_enc_admo(o_ub, p) != 
> NCSCC_RC_SUCCESS) {
>   return NCSCC_RC_OUT_OF_MEM;
>   }
>   p = p->next;
> - ++depth;
>   }
>   
> - if (depth >= IMMSV_MAX_ADMINOWNERS) {
> - LOG_ER("TOO MANY admin owners line:%u", 
> __LINE__);
> - return NCSCC_RC_OUT_OF_MEM;
> - }
> -
> - depth = 0;
>   IMMSV_IMPL_LIST *q = 
> 

Re: [devel] [PATCH 5 of 5] imm: updated README [#195]

[Neelakanta Reddy]

Hi zoran,

will update while pushing the patch.

Thanks,
Neel.

On 2016/08/12 07:35 PM, Zoran Milinkovic wrote:
> Hi Neelakanta,
>
> Find the typo comment inline
>
> -Original Message-
> From: reddy.neelaka...@oracle.com [mailto:reddy.neelaka...@oracle.com]
> Sent: den 27 juli 2016 10:32
> To: Zoran Milinkovic; Hung Duc Nguyen
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 5 of 5] imm: updated README [#195]
>
>   osaf/services/saf/immsv/README |  43 
> ++
>   1 files changed, 43 insertions(+), 0 deletions(-)
>
>
> diff --git a/osaf/services/saf/immsv/README b/osaf/services/saf/immsv/README
> --- a/osaf/services/saf/immsv/README
> +++ b/osaf/services/saf/immsv/README
> @@ -2846,6 +2846,49 @@ been bound on the local node by the same
>   Applier name continues to be shared between nodes, while object and class
>   applier bindings are kept on the originating node.
>   
> +IMM Hardcoded limits as config parameters (5.1)
> +===
> +http://sourceforge.net/p/opensaf/tickets/195/
> +
> +The enhancemnets makes IMM limts configurable. The limits like maxClasses,
>
> [Zoran] Typo, "limts" instead of "limits"
>
> Thanks,
> Zoran
>
> +maxImplementers, maxAdminowners and maxCcbs are allowed as configurable.
> +The limits are added as attributes to the imm object
> +"opensafImm=opensafImm,safApp=safImmService".
> +
> +The default values configured for these attributes are :
> +
> +IMMSV_MAX_CLASSES 1000
> +IMMSV_MAX_IMPLEMENTERS 3000
> +IMMSV_MAX_ADMINOWNERS 2000
> +IMMSV_MAX_CCBS 1
> +
> +The user can not configure the values less than the default values.
> +
> +Notes on upgrading from OpenSAF 5.0 to OpenSAF 5.1
> +
> +OpenSAF5.1 makes the IMM attributes as configurable (#195).
> +During a rolling upgrade from an earlier OpenSAF release to the 5.1
> +release there will be nodes executing the older release concurrently
> +with nodes executing OpenSAF 5.0. Nodes executing the earlier release will 
> not
> +recognize the new attributes introduced in imm config object from nodes 
> executing 5.0.
> +
> +Because of this upgrade issue, the new attribute flag added in OpenSAF 5.1 is
> +not allowed unless a flag is toggled on in the opensafImmNostdFlags runtime
> +attribute in the object:
> +
> +   opensafImm=opensafImm,safApp=safImmService.
> +
> +The following shell command must be used once all nodes are upgraded :
> +
> +immadm -o 1 -p opensafImmNostdFlags:SA_UINT32_T:256 \
> +   opensafImm=opensafImm,safApp=safImmService
> +
> +This will set bit 9 of the 'opensafImmNostdFlags' runtime attribute inside 
> the immsv.
> +Operation-id '1' invoked on the object:
> +
> + 'opensafImm=opensafImm,safApp=safImmService'
> +
> +
>   
>   
>   DEPENDENCIES


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

[devel] [PATCH 1 of 1] cpd: handle BAD_HANDLE from saClmDispatch [#1822]

[Hoang Vo]

 osaf/services/saf/cpsv/cpd/cpd_init.c |  67 ++-
 1 files changed, 66 insertions(+), 1 deletions(-)


Problem:
---
cpd doesn't seem to currently recover from BAD_HANDLE when calling 
saClmDispatch()
This is important if a node is promoted to a controller.

Solution:

Re-initialize CLM HANDLE

diff --git a/osaf/services/saf/cpsv/cpd/cpd_init.c 
b/osaf/services/saf/cpsv/cpd/cpd_init.c
--- a/osaf/services/saf/cpsv/cpd/cpd_init.c
+++ b/osaf/services/saf/cpsv/cpd/cpd_init.c
@@ -61,6 +61,8 @@ static uint32_t cpd_lib_destroy(CPD_DEST
 
 static bool cpd_clear_mbx(NCSCONTEXT arg, NCSCONTEXT msg);
 
+static SaAisErrorT cpd_clm_init_bg(CPD_CB *cb);
+
 void cpd_main_process(CPD_CB *cb);
 
 /
@@ -200,6 +202,63 @@ done:
 }
 
 /
+ * Name  : cpd_clm_init_thread
+ *
+ * Description   : This function is thread function to initialize clm
+ *
+ * Arguments : -
+ *
+ * Return Values : -
+ *
+ * Notes : None.
+ */
+static void* cpd_clm_init_thread(void* arg)
+{
+   CPD_CB *cb = (CPD_CB*)arg;
+
+   TRACE_ENTER();
+
+   SaAisErrorT rc = cpd_clm_init(cb);
+   if (rc != SA_AIS_OK) {
+   exit(EXIT_FAILURE);
+   }
+
+   /* Notify main process to update clm select object */
+   ncs_sel_obj_ind((NCS_SEL_OBJ*)>clm_sel_obj);
+
+   TRACE_LEAVE();
+   return NULL;
+}
+
+/
+ * Name  : cpd_clm_init_bg
+ *
+ * Description   : This function is to start initialize clm thread
+ *
+ * Arguments : -
+ *
+ * Return Values : -
+ *
+ * Notes : None.
+ */
+static SaAisErrorT cpd_clm_init_bg(CPD_CB *cb)
+{
+   pthread_t thread;
+   pthread_attr_t attr;
+   pthread_attr_init();
+   pthread_attr_setdetachstate(, PTHREAD_CREATE_DETACHED);
+
+   if (pthread_create(, , cpd_clm_init_thread, cb) != 0) {
+   LOG_ER("pthread_create FAILED: %s", strerror(errno));
+   exit(EXIT_FAILURE);
+   }
+
+   pthread_attr_destroy();
+
+   return SA_AIS_OK;
+}
+
+/
  * Name  : cpd_lib_init
  *
  * Description   : This is the function which initalize the CPD libarary.
@@ -572,7 +631,13 @@ void cpd_main_process(CPD_CB *cb)
if (fds[FD_CLM].revents & POLLIN) {
/* dispatch all the CLM pending function */
error = saClmDispatch(cb->clm_hdl, SA_DISPATCH_ALL);
-   if (error != SA_AIS_OK) {
+   if (error == SA_AIS_ERR_BAD_HANDLE) {
+   LOG_NO("Bad CLM handle. Reinitializing.");
+   osaf_nanosleep();
+   cpd_clm_init_bg(cb);
+   /* Ignore the FD_CLM */
+   fds[FD_CLM].fd = -1;
+   } else if (error != SA_AIS_OK) {
LOG_ER("saClmDispatch failed: %u", error);
}
}

--
___
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 cpd: handle BAD_HANDLE from saClmDispatch [#1822]

[Hoang Vo]

Summary: cpd: handle BAD_HANDLE from saClmDispatch [#1822]
Review request for Trac Ticket(s): #1822
Peer Reviewer(s): mahesh.va...@oracle.com; anders.wid...@ericsson.com
Pull request to: mahesh.va...@oracle.com
Affected branch(es): default
Development branch: default


Impacted area   Impact y/n

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


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

changeset 25bbd0d6aea119774155b8794c473d73d0dc9b2e
Author: Hoang Vo 
Date:   Tue, 16 Aug 2016 13:21:06 +0700

cpd: handle BAD_HANDLE from saClmDispatch [#1822]

Problem:
--- cpd doesn't seem to currently recover from BAD_HANDLE when 
calling
saClmDispatch() This is important if a node is promoted to a controller.

Solution:
 Re-initialize CLM HANDLE


Complete diffstat:
--
 osaf/services/saf/cpsv/cpd/cpd_init.c |  67 
++-
 1 files changed, 66 insertions(+), 1 deletions(-)


Testing Commands:
-
Run osaftest: nosetests -sv osaftest/tests/ckpt/test_ckpt_suite.py
Run roaming SC test case: nosetests 
osaftest/tests/eriFeature/roamingSc/test_reallocation_after_headless_state.py:TestRoamingSc006.test_roamingSc006_1

Testing, Expected Results:
--
All test cases must pass

Conditions of Submission:
-
ACK from maintainer

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] osafclmna[5375]: ER Exiting

[A V Mahesh]

I was starting SC-2 as Active

-AVM


On 8/16/2016 12:07 PM, A V Mahesh wrote:
> Hi Zoran Milinkovic,
>
> It seems some problem with thees patches :
>
> Opensaf is not comingup with error  `SC-2 osafclmna[5375]: ER*SC-2m* 
> is not a configured node` & ` SC-2 osafclmna[5375]: ER Exiting`
>
> =
> changeset:   7855:bc669776cf7f
> tag: tip
> user:Zoran Milinkovic 
> date:Mon Aug 15 09:38:00 2016 +0530
> summary: clm: add support for long RDN [#1906]
>
> changeset:   7854:e9a1f9f7e1fb
> parent:  7851:6ba070e84429
> user:Zoran Milinkovic 
> date:Mon Aug 15 09:22:54 2016 +0530
> summary: clm: fix return error codes in IMM callbacks [#1917]
>
> changeset:   7853:b0aa865e70df
> branch:  opensaf-5.0.x
> parent:  7844:c603424ffe8d
> user:Zoran Milinkovic 
> date:Mon Aug 15 09:22:54 2016 +0530
> summary: clm: fix return error codes in IMM callbacks [#1917]
>
>
> =
>
>
> Configured Opensaf as follws :
>
>  ./bootstrap.sh ;./configure --enable-imm-pbe --enable-tests 
> --enable-tipc --enable-ntf-imcn
>
>
>
> Aug 16 12:00:09 SC-2 osafntfimcnd[5448]: NO Started
> Aug 16 12:00:09 SC-2 osafclmd[5455]: Started
> Aug 16 12:00:09 SC-2 osafimmnd[5414]: NO Implementer connected: 4 
> (safClmService) <21, 2020f>
> Aug 16 12:00:09 SC-2 osafimmnd[5414]: NO implementer for class 
> 'SaClmNode' is safClmService => class extent is safe.
> Aug 16 12:00:09 SC-2 osafimmnd[5414]: NO implementer for class 
> 'SaClmCluster' is safClmService => class extent is safe.
> Aug 16 12:00:09 SC-2 osafclmd[5455]: NO Node 'SC-2m' requests to join 
> the cluster but is unconfigured
> Aug 16 12:00:09 SC-2 osafclmna[5375]: ER SC-2m is not a configured node
> Aug 16 12:00:09 SC-2 osafclmna[5375]: ER Exiting
> Aug 16 12:00:10 SC-2 osafamfd[5465]: Started
> Aug 16 12:00:10 SC-2 osafimmnd[5414]: NO Implementer connected: 5 
> (safAmfService) <26, 2020f>
> Aug 16 12:00:10 SC-2 osafimmnd[5414]: NO implementer for class 
> 'SaAmfCompBaseType' is safAmfService => class extent is safe.
> Aug 16 12:00:10 SC-2 osafimmnd[5414]: NO implementer for class 
> 'SaAmfSUBaseType' is safAmfServ
>
> -AVM


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

[devel] osafclmna[5375]: ER Exiting

[A V Mahesh]

Hi Zoran Milinkovic,

It seems some problem with thees patches :

Opensaf is not comingup with error  `SC-2 osafclmna[5375]: ER*SC-2m* is 
not a configured node` & ` SC-2 osafclmna[5375]: ER Exiting`

=
changeset:   7855:bc669776cf7f
tag: tip
user:Zoran Milinkovic 
date:Mon Aug 15 09:38:00 2016 +0530
summary: clm: add support for long RDN [#1906]

changeset:   7854:e9a1f9f7e1fb
parent:  7851:6ba070e84429
user:Zoran Milinkovic 
date:Mon Aug 15 09:22:54 2016 +0530
summary: clm: fix return error codes in IMM callbacks [#1917]

changeset:   7853:b0aa865e70df
branch:  opensaf-5.0.x
parent:  7844:c603424ffe8d
user:Zoran Milinkovic 
date:Mon Aug 15 09:22:54 2016 +0530
summary: clm: fix return error codes in IMM callbacks [#1917]


=


Configured Opensaf as follws :

  ./bootstrap.sh ;./configure --enable-imm-pbe --enable-tests 
--enable-tipc --enable-ntf-imcn



Aug 16 12:00:09 SC-2 osafntfimcnd[5448]: NO Started
Aug 16 12:00:09 SC-2 osafclmd[5455]: Started
Aug 16 12:00:09 SC-2 osafimmnd[5414]: NO Implementer connected: 4 
(safClmService) <21, 2020f>
Aug 16 12:00:09 SC-2 osafimmnd[5414]: NO implementer for class 
'SaClmNode' is safClmService => class extent is safe.
Aug 16 12:00:09 SC-2 osafimmnd[5414]: NO implementer for class 
'SaClmCluster' is safClmService => class extent is safe.
Aug 16 12:00:09 SC-2 osafclmd[5455]: NO Node 'SC-2m' requests to join 
the cluster but is unconfigured
Aug 16 12:00:09 SC-2 osafclmna[5375]: ER SC-2m is not a configured node
Aug 16 12:00:09 SC-2 osafclmna[5375]: ER Exiting
Aug 16 12:00:10 SC-2 osafamfd[5465]: Started
Aug 16 12:00:10 SC-2 osafimmnd[5414]: NO Implementer connected: 5 
(safAmfService) <26, 2020f>
Aug 16 12:00:10 SC-2 osafimmnd[5414]: NO implementer for class 
'SaAmfCompBaseType' is safAmfService => class extent is safe.
Aug 16 12:00:10 SC-2 osafimmnd[5414]: NO implementer for class 
'SaAmfSUBaseType' is safAmfServ

-AVM

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

Re: [devel] [PATCH 6 of 8] cpsv: Apply new messages supporting extended SaNameT to CPD, CPND, and CPA v1 [#1574]

[Vo Minh Hoang]

Dear Mahesh,

Thank you very much for your clarifying.
When other service did also, I will update and provide patch that don't use
new messages.

Thank you and best regards,
Hoang


-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com] 
Sent: Tuesday, August 16, 2016 11:29 AM
To: Vo Minh Hoang 
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 6 of 8] cpsv: Apply new messages supporting extended
SaNameT to CPD, CPND, and CPA v1 [#1574]

Hi Hoang,

Please find my responses as [AVM].

-AVM

On 8/15/2016 8:16 AM, Vo Minh Hoang wrote:
> Dear Mahesh,
>
> Thank you very much for your review.
> I would like to answer to your concern.
>
> The solution of adding new messages instead of updating old one mostly 
> because Long DN function has been working in current system (other 
> modules already support long DN).
[AVM]  Long DN  is being introduced in this release in all services
opensaf-5.1.x , so Opensaf rule is that any newly introduce
enhancement/feature functionality can be used once Cluster is completely
upgraded to new version ( all nodes with opensaf-5.1.x )  , so while
upgrading (in-service ) the  SA_ENABLE_EXTENDED_NAMES  will be false , so
their is no way that other modules already support long DN.
So their is not possibility  of  Creating New Long DN  checkpoint while
Upgrading.

>   So if we do not handle this, there are cases that CKPT is in-service 
> update in Long DN enabling nodes and run with Long DN function 
> immediately (Old checkpoint still short DN when previous CKPT version 
> does not support Long DN, just other service) and new updated CKPT 
> will send same message with different format to old CKPT cause 
> strangle behavior.
[AVM]  Accommodating existing checkpoint with Short DN  on newly
upgrading/upgraded  cluster checkpoint code  logic will be the aim of this
path ( please remember while upgrading SA_ENABLE_EXTENDED_NAMES  will be
false). The new logic Long DN variables is higher and will all ways
accommodate Short DN existing checkpoint information.

This patch case we don't need to handle message that will come  LONG DN ,
this path only need to take care of accommodating the existing short DN name
checkpoint names in a new data structures locally.

General comment : Even for each case of supporting servicemen upgrade, if we
were go on adding new event , by this time
opensaf might be having thousands of new event ,you can find some  
old patches of that handle in-service upgrade with out adding new event.

-AVM

> Please consider about it.
>
> Thank you and best regards,
> Hoang
>
>
> -Original Message-
> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
> Sent: Friday, August 12, 2016 12:49 PM
> To: Hoang Vo 
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 6 of 8] cpsv: Apply new messages supporting 
> extended SaNameT to CPD, CPND, and CPA v1 [#1574]
>
> Hi Hoang,
>
> We don't required any new event like CPND_EVT_D2ND_CKPT_CREATE_2 even 
> though NEW CPND might might be sending event to OLD CPD.
>
> In general Opensaf rule is that any newly introduce 
> enhancement/feature functionality can be used once Cluster is 
> completely upgraded to new version.So while upgrading (in-service ) 
> the  SA_ENABLE_EXTENDED_NAMES  will be false  ( longDnsAllowed=0 of 
> opensafImm=opensafImm,safApp=safImmService)
> , once clusters upgraded to new version then only ongDnsAllowed set to 
> 1, ("immcfg -o safImmService -m 
> opensafImm=opensafImm,safApp=safImmService -a
> longDnsAllowed=1") so remove new event merge the content in to a 
> single exist old event , and do additionl functonality  based on the 
> state of
> longDnsAllowed=1 or 0
>
> -AVM
>
> On 7/21/2016 3:04 PM, Hoang Vo wrote:
>>osaf/libs/agents/saf/cpa/cpa_api.c  |  12 +---
>>osaf/libs/agents/saf/cpa/cpa_mds.c  |   2 +-
>>osaf/libs/common/cpsv/cpsv_evt.c|   1 +
>>osaf/services/saf/cpsv/cpd/cpd_evt.c|  10 +++---
>>osaf/services/saf/cpsv/cpd/cpd_mds.c|   3 ++-
>>osaf/services/saf/cpsv/cpd/cpd_proc.c   |   2 +-
>>osaf/services/saf/cpsv/cpnd/cpnd_evt.c  |  26
--
>>osaf/services/saf/cpsv/cpnd/cpnd_mds.c  |   4 ++--
>>osaf/services/saf/cpsv/cpnd/cpnd_proc.c |   6 +++---
>>9 files changed, 42 insertions(+), 24 deletions(-)
>>
>>
>> diff --git a/osaf/libs/agents/saf/cpa/cpa_api.c
> b/osaf/libs/agents/saf/cpa/cpa_api.c
>> --- a/osaf/libs/agents/saf/cpa/cpa_api.c
>> +++ b/osaf/libs/agents/saf/cpa/cpa_api.c
>> @@ -880,6 +880,8 @@ SaAisErrorT saCkptCheckpointOpen(SaCkptH
>>  }
>>
>>  ckpt_name = osaf_extended_name_borrow(checkpointName);
>> +if (strlen(ckpt_name) >= kOsafMaxDnLength)
>> +return SA_AIS_ERR_INVALID_PARAM;
>>
>>  /* SA_AIS_ERR_INVALID_PARAM, bullet 4 in SAI-AIS-CKPT-B.02.02
>>   Section 3.6.1 saCkptCheckpointOpen() and
> saCkptCheckpointOpenAsync(), Return Values */
>>