[devel] [PATCH 1 of 1] amf: README file for long DN support [#1642]
osaf/services/saf/amf/README | 72 1 files changed, 72 insertions(+), 0 deletions(-) diff --git a/osaf/services/saf/amf/README b/osaf/services/saf/amf/README new file mode 100755 --- /dev/null +++ b/osaf/services/saf/amf/README @@ -0,0 +1,72 @@ +# +# -*- OpenSAF -*- +# +# (C) Copyright 2016 The OpenSAF Foundation +# +# This program is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY +# or FITNESS FOR A PARTICULAR PURPOSE. This file and program are licensed +# under the GNU Lesser General Public License Version 2.1, February 1999. +# The complete license can be accessed from the following location: +# http://opensource.org/licenses/lgpl-license.php +# See the Copying file included with the OpenSAF distribution for full +# licensing terms. +# +# Author(s): Ericsson AB +# + +GENERAL +--- + +This is a description of how the AMF service supports long DNs. +Ticket: https://sourceforge.net/p/opensaf/tickets/1642 +This enhancement is part of the general enhancement for supporting long +DNs in OpenSAF introduced by ticket: #191. Ticket #1642 adds support for +long DNs to AMF. + +CONFIGURATION +- + +To enable support for long DNs/RDNs in IMM, the longDnsAllowed +attribute must be enabled using the following command: + +immcfg -a longDnsAllowed=1 opensafImm=opensafImm,safApp=safImmService + +The IMM service will reject attempts to set the longDnsAllowed attribute +back to 0 if the IMM database contains objects with DNs longer than 255 bytes +or RDNs longer than 64 bytes. + +To enable long DN support, an application must follow these things: +- Compile the application with the SA_EXTENDED_NAME_SOURCE preprocessor +macro defined. +- Set the environment variable SA_ENABLE_EXTENDED_NAMES to 1 before +the first call to any SAF API. +- Treat the SaNameT type as opaque and use the SaNameT tunnelling primitives +saAisNameLend(), saAisNameBorrow() to manipulate SaNameT variables. + +IMPLEMENTATION DETAILS +-- + +The implementation has been adapted to the "tunnelling" solution provided +by the OpenSAF generic patch (#191). +Please see the document below on how to use the SaNameT tunnelling primitives: +OpenSAF_Extensions_PR.odt + +This implementation also includes following enhancements: +1) Replace internal SaNameT variables with std::string variables in amfd, amfnd. +2) Replace patricia trees with std::map in amfnd. + +saAmfDispatch() may return SA_AIS_ERR_NAME_TOO_LONG if an application which +does not support long DN, receives an AMF callback containing a long DN entity. +An application should not be configured with long DN entities until long DN +support has been added. + +In AMF B.01.01 spec, the application can free extended SaNameT variables in +SaAmfProtectionGroupNotificationBufferT using the example below: +SaAmfProtectionGroupNotificationBufferT buff; +... +for ( i=0; i +SA_MAX_UNEXTENDED_NAME_LENGTH) +free(saAisNameBorrow(buff.notification[i].member.comp_name)); +} -- ___ 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 amf: README file for long DN support [#1642]
Summary: amf: README file for long DN support [#1642] Review request for Trac Ticket(s): #1642 Peer Reviewer(s): AMF devs Pull request to: AMF maintainers Affected branch(es): default Development branch: default Impacted area Impact y/n Docsy Build systemn RPM/packaging n Configuration files n Startup scripts n SAF servicesn OpenSAF servicesn Core libraries n Samples n Tests n Other n Comments (indicate scope for each "y" above): - <> changeset 4aa0bb1d8315598514beda43e00898ddf4d02467 Author: Long HB Nguyen Date: Tue, 23 Aug 2016 14:06:48 +0700 amf: README file for long DN support [#1642] Added Files: osaf/services/saf/amf/README Complete diffstat: -- osaf/services/saf/amf/README | 72 1 files changed, 72 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 3 of 8] cpa: Add support for extended SaNameT [#1574] v1
Dear Mahesh,
I would like to send updated patch following your comment.
When this is minor comment, I send it as attached file.
Sincerely,
Hoang
-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com]
Sent: Monday, August 22, 2016 12:45 PM
To: Hoang Vo
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 3 of 8] cpa: Add support for extended SaNameT [#1574] v1
Hi Hoang,
ACK for [PATCH 3 of 8] with following minor comment
I think API should return SA_AIS_ERR_TOO_BIG = 26 instead of
SA_AIS_ERR_INVALID_PARAM ( please sync-up with other service return values
).
Note : tested default functionality , LONG DN functionality not tested in
full fledged
-AVM
On 8/18/2016 12:48 PM, Hoang Vo wrote:
> osaf/libs/agents/saf/cpa/Makefile.am | 1 +
> osaf/libs/agents/saf/cpa/cpa_api.c | 36
> osaf/libs/agents/saf/cpa/cpa_db.c| 2 +
> osaf/libs/agents/saf/cpa/cpa_mds.c | 2 +-
> osaf/libs/agents/saf/cpa/cpa_proc.c | 2 +-
> osaf/libs/common/cpsv/include/cpa.h | 1 +
> osaf/libs/common/cpsv/include/cpa_cb.h | 2 +-
> osaf/libs/common/cpsv/include/cpa_proc.h | 2 +-
> 8 files changed, 26 insertions(+), 22 deletions(-)
>
>
> diff --git a/osaf/libs/agents/saf/cpa/Makefile.am
> b/osaf/libs/agents/saf/cpa/Makefile.am
> --- a/osaf/libs/agents/saf/cpa/Makefile.am
> +++ b/osaf/libs/agents/saf/cpa/Makefile.am
> @@ -22,6 +22,7 @@ noinst_LTLIBRARIES = libcpa.la
>
> libcpa_la_CPPFLAGS = \
> -DNCS_CPA=1 \
> + -DSA_EXTENDED_NAME_SOURCE \
> $(AM_CPPFLAGS) \
> -I$(top_srcdir)/osaf/libs/common/cpsv/include
>
> 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
> @@ -870,19 +870,20 @@ SaAisErrorT saCkptCheckpointOpen(SaCkptH
> bool locked = false;
> uint32_t time_out=0;
> CPA_GLOBAL_CKPT_NODE *gc_node = NULL;
> + SaConstStringT ckpt_name = NULL;
>
> TRACE_ENTER2("SaCkptCheckpointHandleT passed is %llx",ckptHandle);
> - if ((checkpointName == NULL) || (checkpointHandle == NULL) ||
(checkpointName->length == 0)) {
> + if ((checkpointName == NULL) || (checkpointHandle == NULL) ||
> +(osaf_extended_name_length(checkpointName) == 0)) {
> TRACE_4("Cpa CkptOpen Api failed with return
value:%d,ckptHandle:%llx", SA_AIS_ERR_INVALID_PARAM, ckptHandle);
> TRACE_LEAVE2("API return code = %u", rc);
> return SA_AIS_ERR_INVALID_PARAM;
> }
>
> - m_CPSV_SET_SANAMET(checkpointName);
> + ckpt_name = osaf_extended_name_borrow(checkpointName);
>
> /* SA_AIS_ERR_INVALID_PARAM, bullet 4 in SAI-AIS-CKPT-B.02.02
> Section 3.6.1 saCkptCheckpointOpen() and
saCkptCheckpointOpenAsync(), Return Values */
> -if (strncmp((const char *)checkpointName->value, "safCkpt=", 8)
!= 0) {
> +if (strncmp(ckpt_name, "safCkpt=", 8) != 0) {
> TRACE_4("Cpa CkptOpen:DN failed with return
value:%d,ckptHandle:%llx", SA_AIS_ERR_INVALID_PARAM, ckptHandle);
> TRACE_LEAVE2("API return code = %u", rc);
> return SA_AIS_ERR_INVALID_PARAM;
[AVM] I think this should return SA_AIS_ERR_TOO_BIG = 26 ( please
sync-up with other service return values )
> @@ -909,7 +910,7 @@ SaAisErrorT saCkptCheckpointOpen(SaCkptH
>
>
> /* Draft Validations */
> - rc = cpa_open_attr_validate(checkpointCreationAttributes,
checkpointOpenFlags, checkpointName);
> + rc = cpa_open_attr_validate(checkpointCreationAttributes,
> +checkpointOpenFlags);
> if (rc != SA_AIS_OK) {
> /* No need to log, already logged inside the
cpa_open_attr_validate */
> goto done;
> @@ -965,7 +966,7 @@ SaAisErrorT saCkptCheckpointOpen(SaCkptH
> lc_node->cl_hdl = ckptHandle;
> lc_node->open_flags = checkpointOpenFlags;
>
> - lc_node->ckpt_name = *checkpointName;
> + lc_node->ckpt_name = strdup(ckpt_name);
>
> /* Add CPA_LOCAL_CKPT_NODE to lcl_ckpt_hdl_tree */
> proc_rc = cpa_lcl_ckpt_node_add(&cb->lcl_ckpt_tree, lc_node); @@
> -984,7 +985,7 @@ SaAisErrorT saCkptCheckpointOpen(SaCkptH
> evt.info.cpnd.info.openReq.client_hdl = ckptHandle;
> evt.info.cpnd.info.openReq.lcl_ckpt_hdl = lc_node->lcl_ckpt_hdl;
>
> - evt.info.cpnd.info.openReq.ckpt_name = *checkpointName;
> + osaf_extended_name_lend(ckpt_name,
> +&evt.info.cpnd.info.openReq.ckpt_name);
>
> if (checkpointCreationAttributes) {
> evt.info.cpnd.info.openReq.ckpt_attrib =
> *checkpointCreationAttributes; @@ -1128,6 +1129,7 @@ gl_node_add_fail:
>
>lc_node_add_fail:
> if (lc_node != NULL) {
> + free((void *)lc_node->ckpt_name);
> m_MMGR_FREE_CPA_LOCAL_CKPT_NODE(lc_node);
> }
>
> @@ -1179,6 +1181,7 @@ SaAisErrorT saCkptCheckpointOpe
Re: [devel] [PATCH 4 of 8] cpsv: Add new message to support extended SaNameT [#1574] v3
Dear Mahesh,
I would like to send updated patch following your comment.
When this is minor comment, I send it as attached file.
Sincerely,
Hoang
-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com]
Sent: Monday, August 22, 2016 12:55 PM
To: Hoang Vo
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 4 of 8] cpsv: Add new message to support extended
SaNameT [#1574] v3
Hi Hoang,
ACK for [PATCH 4 of 8] assuming unrequited comment code will be removed
Note : tested default functionality , LONG DN functionality not tested in
full fledged
-AVM
On 8/18/2016 12:48 PM, Hoang Vo wrote:
> osaf/libs/common/cpsv/cpsv_evt.c | 439
+-
> osaf/libs/common/cpsv/include/cpsv_evt.h | 10 +
> osaf/services/saf/cpsv/cpd/cpd_mds.c | 84 +-
> osaf/services/saf/cpsv/cpnd/cpnd_mds.c | 86 +-
> 4 files changed, 581 insertions(+), 38 deletions(-)
>
>
> diff --git a/osaf/libs/common/cpsv/cpsv_evt.c
> b/osaf/libs/common/cpsv/cpsv_evt.c
> --- a/osaf/libs/common/cpsv/cpsv_evt.c
> +++ b/osaf/libs/common/cpsv/cpsv_evt.c
> @@ -30,11 +30,14 @@
>
> #include "cpsv.h"
> #include "cpa_tmr.h"
> +#include "osaf_extended_name.h"
>
> FUNC_DECLARATION(CPSV_CKPT_DATA);
> static SaCkptSectionIdT *cpsv_evt_dec_sec_id(NCS_UBAID *i_ub, uint32_t
svc_id);
> static uint32_t cpsv_evt_enc_sec_id(NCS_UBAID *o_ub, SaCkptSectionIdT
*sec_id);
> static void cpsv_convert_sec_id_to_string(char *sec_id_str,
> SaCkptSectionIdT *section_id);
> +static uint32_t cpsv_encode_extended_name_flat(NCS_UBAID *uba,
> +SaNameT *name); static uint32_t
> +cpsv_decode_extended_name_flat(NCS_UBAID *uba, SaNameT *name);
>
> const char *cpa_evt_str[] = {
> "STRING_0",
> @@ -254,8 +257,8 @@ char* cpsv_evt_str(CPSV_EVT *evt, char *
> case CPND_EVT_A2ND_CKPT_OPEN:
> {
> CPSV_A2ND_OPEN_REQ *info =
&evt->info.cpnd.info.openReq;
> - snprintf(o_evt_str, len,
"CPND_EVT_A2ND_CKPT_OPEN(hdl=%llu, %s)",
> - info->client_hdl, info->ckpt_name.value);
> + snprintf(o_evt_str, len,
"CPND_EVT_A2ND_CKPT_OPEN_2(hdl=%llu, %s)",
> + info->client_hdl,
osaf_extended_name_borrow(&info->ckpt_name));
> break;
> }
> case CPND_EVT_A2ND_CKPT_CLOSE:
> @@ -268,7 +271,7 @@ char* cpsv_evt_str(CPSV_EVT *evt, char *
> case CPND_EVT_A2ND_CKPT_UNLINK:
> {
> CPSV_A2ND_CKPT_UNLINK *info =
&evt->info.cpnd.info.ulinkReq;
> - snprintf(o_evt_str, len,
"CPND_EVT_A2ND_CKPT_UNLINK(%s)", info->ckpt_name.value);
> + snprintf(o_evt_str, len,
"CPND_EVT_A2ND_CKPT_UNLINK_2(%s)",
> +osaf_extended_name_borrow(&info->ckpt_name));
> break;
> }
> case CPND_EVT_A2ND_CKPT_RDSET:
> @@ -513,12 +516,22 @@ char* cpsv_evt_str(CPSV_EVT *evt, char *
> case CPND_EVT_D2ND_CKPT_CREATE:
> {
> CPSV_D2ND_CKPT_CREATE *info =
&evt->info.cpnd.info.ckpt_create;
> - snprintf(o_evt_str, len, "[%llu]
CPND_EVT_D2ND_CKPT_CREATE(%s, create_rep=%s, active=0x%X)",
> - info->ckpt_info.ckpt_id,
info->ckpt_name.value,
> + snprintf(o_evt_str, len, "[%llu]
CPND_EVT_D2ND_CKPT_CREATE_2(%s, create_rep=%s, is_act=%s, active=0x%X,
dest_cnt=%d)",
> + info->ckpt_info.ckpt_id,
> +osaf_extended_name_borrow(&info->ckpt_name),
> info->ckpt_info.ckpt_rep_create ? "true" :
"false",
> -
m_NCS_NODE_ID_FROM_MDS_DEST(info->ckpt_info.active_dest));
> + info->ckpt_info.is_active_exists ? "true" :
"false",
> +
m_NCS_NODE_ID_FROM_MDS_DEST(info->ckpt_info.active_dest),
> + info->ckpt_info.dest_cnt);
> +
> + SaCkptCheckpointCreationAttributesT *attr =
&info->ckpt_info.attributes;
> + TRACE("mSecS=%lld, flags=%d, mSec=%d, mSecIdS=%lld,
ret=%lld, ckptS=%lld", attr->maxSectionSize,
> + attr->creationFlags, attr->maxSections,
attr->maxSectionIdSize, attr->retentionDuration,
> + attr->checkpointSize);
> + for (int i = 0; i < info->ckpt_info.dest_cnt; i++)
> + TRACE("dest[%d] = 0x%" PRIX64 " ", i,
> +info->ckpt_info.dest_list[i].dest);
> break;
> }
> +
> case CPND_EVT_D2ND_CKPT_DESTROY:
> {
> snprintf(o_evt_str, len, "[%llu]
CPND_EVT_D2ND_CKPT_DESTROY",
> evt->info.cpnd.info.ckpt_destroy.ckpt_id);
> @@ -608,8 +621,8 @@ char* cpsv_evt_str(CPSV_EVT *evt, char *
> case CPND_EVT_A2ND_CKPT_LIST_UPDATE:
> {
> CPSV_A2ND_CKPT_LIST_UPD
Re: [devel] [PATCH 6 of 8] cpsv: Apply new messages supporting extended SaNameT to CPD, CPND, and CPA [#1574] v4
Dear Mahesh,
I would like to send updated patch following your comment.
When this is minor comment, I send it as attached file.
Sincerely,
Hoang
-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com]
Sent: Monday, August 22, 2016 1:02 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 [#1574] v4
Hi Hoang,
ACK for [PATCH 6 of 8] with following minor comment
I think CPND should return SA_AIS_ERR_TOO_BIG = 26 instead of
SA_AIS_ERR_INVALID_PARAM ( please sync-up with other service return values
).
Note : tested default functionality , LONG DN functionality not tested in
full fledged
-AVM
On 8/18/2016 12:48 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_proc.c | 2 +-
> osaf/services/saf/cpsv/cpnd/cpnd_evt.c | 2 ++
> osaf/services/saf/cpsv/cpnd/cpnd_proc.c | 2 +-
> 6 files changed, 18 insertions(+), 3 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,10 @@ SaAisErrorT saCkptCheckpointOpen(SaCkptH
> }
>
> ckpt_name = osaf_extended_name_borrow(checkpointName);
> + if (strlen(ckpt_name) >= kOsafMaxDnLength) {
> + TRACE_LEAVE2("API return code = %u",
SA_AIS_ERR_INVALID_PARAM);
> + 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 */ @@ -1192,6 +1196,10 @@
SaAisErrorT saCkptCheckpointOpenAsync(Sa
> }
>
> ckpt_name = osaf_extended_name_borrow(checkpointName);
> + if (strlen(ckpt_name) >= kOsafMaxDnLength) {
> + TRACE_LEAVE2("API return code = %u",
SA_AIS_ERR_INVALID_PARAM);
> + 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 */ @@ -1597,6 +1605,10 @@
SaAisErrorT saCkptCheckpointUnlink(SaCkp
> }
>
> ckpt_name = osaf_extended_name_borrow(checkpointName);
> + if (strlen(ckpt_name) >= kOsafMaxDnLength) {
> + TRACE_LEAVE2("API return code = %u",
SA_AIS_ERR_INVALID_PARAM);
> + return SA_AIS_ERR_INVALID_PARAM;
> + }
>
> /* retrieve CPA CB */
> m_CPA_RETRIEVE_CB(cb);
> diff --git a/osaf/libs/agents/saf/cpa/cpa_mds.c
> b/osaf/libs/agents/saf/cpa/cpa_mds.c
> --- a/osaf/libs/agents/saf/cpa/cpa_mds.c
> +++ b/osaf/libs/agents/saf/cpa/cpa_mds.c
> @@ -515,9 +515,9 @@ static uint32_t cpa_mds_svc_evt(CPA_CB *
> /* Populate & Send the Open Event to CPND */
> memset(&evt, 0, sizeof(CPSV_EVT));
> evt.type = CPSV_EVT_TYPE_CPND;
> -evt.info.cpnd.type = CPND_EVT_A2ND_CKPT_LIST_UPDATE;
> evt.info.cpnd.info.ckptListUpdate.client_hdl =
lc_node->cl_hdl;
> osaf_extended_name_lend(lc_node->ckpt_name,
> &evt.info.cpnd.info.ckptListUpdate.ckpt_name);
> +evt.info.cpnd.type = CPND_EVT_A2ND_CKPT_LIST_UPDATE;
>
> proc_rc = cpa_mds_msg_send(cb->cpa_mds_hdl,
&cb->cpnd_mds_dest,
> &evt, NCSMDS_SVC_ID_CPND);
>
> diff --git a/osaf/libs/common/cpsv/cpsv_evt.c
> b/osaf/libs/common/cpsv/cpsv_evt.c
> --- a/osaf/libs/common/cpsv/cpsv_evt.c
> +++ b/osaf/libs/common/cpsv/cpsv_evt.c
> @@ -2378,6 +2378,7 @@ static uint32_t cpsv_encode_extended_nam
> if(!osaf_is_an_extended_name(name))
> return NCSCC_RC_SUCCESS;
>
> + TRACE("length = %d", name->length);
> SaConstStringT value = osaf_extended_name_borrow(name);
> uint16_t length = osaf_extended_name_length(name);
>
> diff --git a/osaf/services/saf/cpsv/cpd/cpd_proc.c
> b/osaf/services/saf/cpsv/cpd/cpd_proc.c
> --- a/osaf/services/saf/cpsv/cpd/cpd_proc.c
> +++ b/osaf/services/saf/cpsv/cpd/cpd_proc.c
> @@ -61,9 +61,9 @@ uint32_t cpd_noncolloc_ckpt_rep_create(C
> /* Send the Replica create info to CPND */
> memset(&send_evt, 0, sizeof(CPSV_EVT));
> send_evt.type = CPSV_EVT_TYPE_CPND;
> - send_evt.info.cpnd.type = CPND_EVT_D2ND_CKPT_CREATE;
>
> osaf_extended_name_lend(map_info->ckpt_name,
> &send_evt.info.cpnd.info.ckpt_create.ckpt_name);
> + send_evt.info.cpnd.type = CPND_EVT_D2ND_CKPT_CREATE;
>
> d2nd_info = &send_evt.info.cpnd.info.ckpt_create.ckpt_info;
>
> diff --git a/osaf/services/saf/cpsv/cpnd/cpnd_evt.c
> b/osaf/services/saf/cpsv/cpnd/cpnd_evt.c
> --- a/osaf/services/saf/cpsv/cpnd/cpnd_evt.c
> +++ b/osaf/services
Re: [devel] [PATCH 0 of 8] Review Request for CKPT: Support DNs longer than 255 bytes [#1574] v5
Dear Mahesh,
I updated README file and sent as attachment to this email.
I also sent update patches following your comments.
Please help me push these items if there is no further problem.
Thank you and best regards,
Hoang
-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com]
Sent: Monday, August 22, 2016 1:53 PM
To: Hoang Vo
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 0 of 8] Review Request for CKPT: Support DNs longer than
255 bytes [#1574] v5
Hi Hoang,
ACK, Please Update README
Note : tested default functionality , LONG DN functionality not tested in
full fledged.
-AVM
On 8/18/2016 12:48 PM, Hoang Vo wrote:
> Summary: CKPT: Support DNs longer than 255 bytes {#1574} Review
> request for Trac Ticket(s): 1574 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 05233bdae1fb000fea001964eba1c51ebf3bfd8e
> Author: Hoang Vo
> Date: Thu, 18 Aug 2016 13:51:56 +0700
>
> cpd: Add support for extended SaNameT [#1574] v3
>
> changeset cecabec5b6be73e731e540fd439e1d0e3534809f
> Author: Hoang Vo
> Date: Thu, 18 Aug 2016 13:51:56 +0700
>
> cpnd: Add support for extended SaNameT [#1574] v3
>
> changeset 940dc877c94a9539e3da06d89c6480ef7e0ceda0
> Author: Hoang Vo
> Date: Thu, 18 Aug 2016 13:51:56 +0700
>
> cpa: Add support for extended SaNameT [#1574] v1
>
> changeset 1f74531a36163bdfecd6b27174443d51c11ecf61
> Author: Hoang Vo
> Date: Thu, 18 Aug 2016 13:51:56 +0700
>
> cpsv: Add new message to support extended SaNameT [#1574] v3
>
> changeset 29df19302186b3275ad06db00dc62f275dea25e1
> Author: Hoang Vo
> Date: Thu, 18 Aug 2016 13:51:56 +0700
>
> cpd: Add new mbcsv messages supporting extended SaNameT [#1574] v2
>
> changeset 3f72410a7c2bb077647bdd4e46869a31a832f1d8
> Author: Hoang Vo
> Date: Thu, 18 Aug 2016 13:51:56 +0700
>
> cpsv: Apply new messages supporting extended SaNameT to CPD, CPND,
and CPA
> [#1574] v4
>
> changeset f32a0b3ca1ebf6049d2103e68e91d98bf086c48e
> Author: Hoang Vo
> Date: Thu, 18 Aug 2016 13:51:56 +0700
>
> ckpt: Add new test cases to verify long DN feature on CPSV [#1574]
v1
>
> changeset 1aa38b707cf2cec14c416631cfc7e5518b25735f
> Author: Hoang Vo
> Date: Thu, 18 Aug 2016 13:51:56 +0700
>
> cpnd: add support for shm recovery for in-service update without
restarting
> node [#1574] v1
>
>
> Complete diffstat:
> --
> osaf/libs/agents/saf/cpa/Makefile.am |1 +
> osaf/libs/agents/saf/cpa/cpa_api.c| 48 --
> osaf/libs/agents/saf/cpa/cpa_db.c |2 +
> osaf/libs/agents/saf/cpa/cpa_mds.c|4 +-
> osaf/libs/agents/saf/cpa/cpa_proc.c |2 +-
> osaf/libs/common/cpsv/cpsv_evt.c | 440
++---
> osaf/libs/common/cpsv/include/cpa.h |1 +
> osaf/libs/common/cpsv/include/cpa_cb.h|2 +-
> osaf/libs/common/cpsv/include/cpa_proc.h |2 +-
> osaf/libs/common/cpsv/include/cpd.h |1 +
> osaf/libs/common/cpsv/include/cpd_cb.h| 17 +-
> osaf/libs/common/cpsv/include/cpd_imm.h |4 +-
> osaf/libs/common/cpsv/include/cpd_mem.h | 25 +++-
> osaf/libs/common/cpsv/include/cpd_proc.h |2 +-
> osaf/libs/common/cpsv/include/cpnd.h |1 +
> osaf/libs/common/cpsv/include/cpnd_cb.h |5 +-
> osaf/libs/common/cpsv/include/cpnd_init.h |3 +-
> osaf/libs/common/cpsv/include/cpsv_evt.h | 10 +
> osaf/libs/common/cpsv/include/cpsv_shm.h | 24 +++-
> osaf/services/saf/cpsv/cpd/Makefile.am|1 +
> osaf/services/saf/cpsv/cpd/cpd_amf.c |7 +-
> osaf/services/saf/cpsv/cpd/cpd_db.c | 95 +++---
> osaf/services/saf/cpsv/cpd/cpd_evt.c | 103 ++-
> osaf/services/saf/cpsv/cpd/cpd_imm.c | 268
++
> osaf/services/saf/cpsv/cpd/cpd_main.c |7 +
> osaf/services/saf/cpsv/cpd/cpd_mbcsv.c| 31 -
> osaf/services/saf/cpsv/cpd/cpd_mds.c | 84 -
> osaf/services/saf/cpsv/cpd/cpd_proc.c | 180
++--
> osaf/services/saf/cpsv/cpd/cpd_red.c |6 +-
> osaf/services/saf/cpsv/cpd/cpd_sbevt.c| 57 +++-
> osaf/services/saf/cp
Re: [devel] [PATCH 6 of 8] cpsv: Apply new messages supporting extended SaNameT to CPD, CPND, and CPA [#1574] v4
Hi Hoang,
Please send the all update patches 1 to 8 , so that I can commit.
-AVM
On 8/23/2016 12:46 PM, Vo Minh Hoang wrote:
> Dear Mahesh,
>
> I would like to send updated patch following your comment.
> When this is minor comment, I send it as attached file.
>
> Sincerely,
> Hoang
>
> -Original Message-
> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
> Sent: Monday, August 22, 2016 1:02 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 [#1574] v4
>
> Hi Hoang,
>
> ACK for [PATCH 6 of 8] with following minor comment
> I think CPND should return SA_AIS_ERR_TOO_BIG = 26 instead of
> SA_AIS_ERR_INVALID_PARAM ( please sync-up with other service return values
> ).
>
> Note : tested default functionality , LONG DN functionality not tested in
> full fledged
>
> -AVM
>
>
> On 8/18/2016 12:48 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_proc.c | 2 +-
>>osaf/services/saf/cpsv/cpnd/cpnd_evt.c | 2 ++
>>osaf/services/saf/cpsv/cpnd/cpnd_proc.c | 2 +-
>>6 files changed, 18 insertions(+), 3 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,10 @@ SaAisErrorT saCkptCheckpointOpen(SaCkptH
>> }
>>
>> ckpt_name = osaf_extended_name_borrow(checkpointName);
>> +if (strlen(ckpt_name) >= kOsafMaxDnLength) {
>> +TRACE_LEAVE2("API return code = %u",
> SA_AIS_ERR_INVALID_PARAM);
>> +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 */ @@ -1192,6 +1196,10 @@
> SaAisErrorT saCkptCheckpointOpenAsync(Sa
>> }
>>
>> ckpt_name = osaf_extended_name_borrow(checkpointName);
>> +if (strlen(ckpt_name) >= kOsafMaxDnLength) {
>> +TRACE_LEAVE2("API return code = %u",
> SA_AIS_ERR_INVALID_PARAM);
>> +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 */ @@ -1597,6 +1605,10 @@
> SaAisErrorT saCkptCheckpointUnlink(SaCkp
>> }
>>
>> ckpt_name = osaf_extended_name_borrow(checkpointName);
>> +if (strlen(ckpt_name) >= kOsafMaxDnLength) {
>> +TRACE_LEAVE2("API return code = %u",
> SA_AIS_ERR_INVALID_PARAM);
>> +return SA_AIS_ERR_INVALID_PARAM;
>> +}
>>
>> /* retrieve CPA CB */
>> m_CPA_RETRIEVE_CB(cb);
>> diff --git a/osaf/libs/agents/saf/cpa/cpa_mds.c
>> b/osaf/libs/agents/saf/cpa/cpa_mds.c
>> --- a/osaf/libs/agents/saf/cpa/cpa_mds.c
>> +++ b/osaf/libs/agents/saf/cpa/cpa_mds.c
>> @@ -515,9 +515,9 @@ static uint32_t cpa_mds_svc_evt(CPA_CB *
>> /* Populate & Send the Open Event to CPND */
>> memset(&evt, 0, sizeof(CPSV_EVT));
>> evt.type = CPSV_EVT_TYPE_CPND;
>> - evt.info.cpnd.type = CPND_EVT_A2ND_CKPT_LIST_UPDATE;
>> evt.info.cpnd.info.ckptListUpdate.client_hdl =
> lc_node->cl_hdl;
>> osaf_extended_name_lend(lc_node->ckpt_name,
>> &evt.info.cpnd.info.ckptListUpdate.ckpt_name);
>> + evt.info.cpnd.type = CPND_EVT_A2ND_CKPT_LIST_UPDATE;
>>
>> proc_rc = cpa_mds_msg_send(cb->cpa_mds_hdl,
> &cb->cpnd_mds_dest,
>> &evt, NCSMDS_SVC_ID_CPND);
>>
>> diff --git a/osaf/libs/common/cpsv/cpsv_evt.c
>> b/osaf/libs/common/cpsv/cpsv_evt.c
>> --- a/osaf/libs/common/cpsv/cpsv_evt.c
>> +++ b/osaf/libs/common/cpsv/cpsv_evt.c
>> @@ -2378,6 +2378,7 @@ static uint32_t cpsv_encode_extended_nam
>> if(!osaf_is_an_extended_name(name))
>> return NCSCC_RC_SUCCESS;
>>
>> +TRACE("length = %d", name->length);
>> SaConstStringT value = osaf_extended_name_borrow(name);
>> uint16_t length = osaf_extended_name_length(name);
>>
>> diff --git a/osaf/services/saf/cpsv/cpd/cpd_proc.c
>> b/osaf/services/saf/cpsv/cpd/cpd_proc.c
>> --- a/osaf/services/saf/cpsv/cpd/cpd_proc.c
>> +++ b/osaf/services/saf/cpsv/cpd/cpd_proc.c
>> @@ -61,9 +61,9 @@ uint32_t cpd_noncolloc_ckpt_rep_create(C
>> /* Send the Replica create info to CPND */
>> memset(&send_evt, 0, sizeof(CPSV_EVT));
>> send_evt.type = CPSV_EVT_TYPE_CPND;
>> -send_evt.info.cpnd.type = CPND_EVT_D2ND_CKPT_CREATE;
>>
>> osaf_extended_name_lend(map_info->ckpt_name,
>> &send_evt.info.cpnd.info.ckpt_create.ckpt_name);
>> +send_evt.info.cpnd.type = CPND_EVT_D2ND_CKPT_
Re: [devel] [PATCH 1 of 1] log: fix failed to recover app streams [#1941]
Hi Mahesh, The folder "/repl_opensaf/saflog/logtest_sc_down_path/" is on UML container. I guess, on your system, the path is different. To get the correct patch to shared log folder, do following: 1) Get the log root folder: # immlist logConfig=1,safApp=safLogService Name Type Value(s) logRootDirectory SA_STRING_T /repl_opensaf/saflog 2) On PL, check if the node can access to shared folder: /logtest_sc_down_path Regards, Vu > -Original Message- > From: A V Mahesh [mailto:mahesh.va...@oracle.com] > Sent: Tuesday, August 23, 2016 1:59 PM > To: Vu Minh Nguyen ; 'Lennart Lund' > > Cc: opensaf-devel@lists.sourceforge.net > Subject: Re: [devel] [PATCH 1 of 1] log: fix failed to recover app streams > [#1941] > > Hi Vu, > > This folder doesn't exist , i just created on PL-3 , still failing > > PL-3:~ # mkdir -p /repl_opensaf/saflog/logtest_sc_down_path/ > PL-3:~ # > > PL-3:~ # /usr/bin/logtest -e 9 > > Suite 9: LOG Server down / up > ; > Preparing 8 streams for test. Please wait... > Preparing stream 0 > ... > Preparing stream 1 > ... > cur_logfile_name_get scandir Fail No such file or > directorysaLogRecov_prepare_client1_8streams Internal error. Test failed > 2 FAILED (expected EXIT_SUCCESS, got EXIT_FAILURE (1))PL-3:~ # > > -AVM > > > On 8/23/2016 12:21 PM, Vu Minh Nguyen wrote: > > Hi Mahesh, > > > > Can you check if PL node can access the shared log folder? > > > > E.g: path on UML test > > /repl_opensaf/saflog/logtest_sc_down_path/ > > > > I guess the problem is caused by PL not able to access the SAF log folder. > > > > Regards, Vu > > > >> -Original Message- > >> From: A V Mahesh [mailto:mahesh.va...@oracle.com] > >> Sent: Tuesday, August 23, 2016 1:46 PM > >> To: Vu Minh Nguyen ; Lennart Lund > >> > >> Cc: opensaf-devel@lists.sourceforge.net > >> Subject: Re: [devel] [PATCH 1 of 1] log: fix failed to recover app streams > >> [#1941] > >> > >> Hi Vu, > >> > >> I got it running on SC , but it is failing on PL with : > >> > >> "cur_logfile_name_get scandir Fail No such file or > >> directorysaLogRecov_prepare_client1_8streams Internal error. Test failed > >> 2 FAILED (expected EXIT_SUCCESS, got EXIT_FAILURE (1))" > >> > >> -AVM > >> > >> > >> On 8/23/2016 12:06 PM, A V Mahesh wrote: > >>> Hi Vu, > >>> > >>> Why test case is allowed on SC`s ? > >>> > >>> > >> > == > >> > >>> SC-1:~ # /usr/bin/logtest -e 9 > >>> > >>> Suite 9: LOG Server down / up > >>>; > >>> Preparing 8 streams for test. Please wait... > >>> Preparing stream 0 > >>> ... > >>> Preparing stream 1 > >>> ... > >>> Preparing stream 2 > >>> ... > >>> Preparing stream 3 > >>> .. > >>> Preparing stream 4 > >>> .. > >>> Preparing stream 5 > >>> . > >>> Preparing stream 6 > >>> Preparing stream 7 > >>>2 PASSED Before SC down: Prepare 8 streams; > >>> Preparing 1 config stream (notification) for test . Please wait... > >>> . > >>>3 PASSED Before SC down: Prepare 1 cfg (notif) stream; > >>> > >>> Stop both SC nodes [stdby first]. Press Enter when stopped... > >>>; > >>> > >>> Start at least one SC node. Press Enter when started... > >>> > >>> > >> > == > >> > >>> -AVM > >>> > >>> On 8/23/2016 12:03 PM, A V Mahesh wrote: > Hi Vu, > > test case 9 failing on PL-3 , i am i missing any configuration ? > > # /usr/bin/logtest -e 9 > > Suite 9: LOG Server down / up > ; > Preparing 8 streams for test. Please wait... > Preparing stream 0 > ... > Preparing stream 1 > ... > cur_logfile_name_get scandir Fail No such file or > directorysaLogRecov_prepare_client1_8streams Internal error. Test > > failed > > -AVM > > On 8/10/2016 12:09 PM, Vu Minh Nguyen wrote: > > osaf/services/saf/logsv/lgs/lgs_recov.cc | 59 > > + > >> -- > > 1 files changed, 32 insertions(+), 27 deletions(-) > > > > > > create_new_app_stream() was changed and introduced new error > codes > >> in long DN > > ticket. One of them is SA_AIS_ERR_EXIST. > > > > When SCs restart from headless, create_new_app_stream() returns > >> SA_AIS_ERR_EXIST > > but this error code was not handled correctly and made recovery > >> functionality > > fail. > > > > lgs_restore_one_app_stream needs to be updated. > > > > diff --git a/osaf/services/saf/logsv/lgs/lgs_recov.cc > >> b/osaf/services/saf/logsv/lgs/lgs_recov.cc > > --- a/osaf/services/saf/logsv/lgs/lgs_recov.cc >
Re: [devel] [PATCH 0 of 8] Review Request for CKPT: Support DNs longer than 255 bytes [#1574] v5
Hi Hoang,
Please send the all update patches 1 to 8 & README in single tar,
so that I can commit.
-AVM
On 8/23/2016 12:48 PM, Vo Minh Hoang wrote:
> Dear Mahesh,
>
> I updated README file and sent as attachment to this email.
> I also sent update patches following your comments.
>
> Please help me push these items if there is no further problem.
>
> Thank you and best regards,
> Hoang
>
> -Original Message-
> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
> Sent: Monday, August 22, 2016 1:53 PM
> To: Hoang Vo
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 0 of 8] Review Request for CKPT: Support DNs longer than
> 255 bytes [#1574] v5
>
> Hi Hoang,
>
> ACK, Please Update README
>
> Note : tested default functionality , LONG DN functionality not tested in
> full fledged.
>
> -AVM
>
>
> On 8/18/2016 12:48 PM, Hoang Vo wrote:
>> Summary: CKPT: Support DNs longer than 255 bytes {#1574} Review
>> request for Trac Ticket(s): 1574 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 05233bdae1fb000fea001964eba1c51ebf3bfd8e
>> Author: Hoang Vo
>> Date:Thu, 18 Aug 2016 13:51:56 +0700
>>
>> cpd: Add support for extended SaNameT [#1574] v3
>>
>> changeset cecabec5b6be73e731e540fd439e1d0e3534809f
>> Author: Hoang Vo
>> Date:Thu, 18 Aug 2016 13:51:56 +0700
>>
>> cpnd: Add support for extended SaNameT [#1574] v3
>>
>> changeset 940dc877c94a9539e3da06d89c6480ef7e0ceda0
>> Author: Hoang Vo
>> Date:Thu, 18 Aug 2016 13:51:56 +0700
>>
>> cpa: Add support for extended SaNameT [#1574] v1
>>
>> changeset 1f74531a36163bdfecd6b27174443d51c11ecf61
>> Author: Hoang Vo
>> Date:Thu, 18 Aug 2016 13:51:56 +0700
>>
>> cpsv: Add new message to support extended SaNameT [#1574] v3
>>
>> changeset 29df19302186b3275ad06db00dc62f275dea25e1
>> Author: Hoang Vo
>> Date:Thu, 18 Aug 2016 13:51:56 +0700
>>
>> cpd: Add new mbcsv messages supporting extended SaNameT [#1574] v2
>>
>> changeset 3f72410a7c2bb077647bdd4e46869a31a832f1d8
>> Author: Hoang Vo
>> Date:Thu, 18 Aug 2016 13:51:56 +0700
>>
>> cpsv: Apply new messages supporting extended SaNameT to CPD, CPND,
> and CPA
>> [#1574] v4
>>
>> changeset f32a0b3ca1ebf6049d2103e68e91d98bf086c48e
>> Author: Hoang Vo
>> Date:Thu, 18 Aug 2016 13:51:56 +0700
>>
>> ckpt: Add new test cases to verify long DN feature on CPSV [#1574]
> v1
>> changeset 1aa38b707cf2cec14c416631cfc7e5518b25735f
>> Author: Hoang Vo
>> Date:Thu, 18 Aug 2016 13:51:56 +0700
>>
>> cpnd: add support for shm recovery for in-service update without
> restarting
>> node [#1574] v1
>>
>>
>> Complete diffstat:
>> --
>>osaf/libs/agents/saf/cpa/Makefile.am |1 +
>>osaf/libs/agents/saf/cpa/cpa_api.c| 48 --
>>osaf/libs/agents/saf/cpa/cpa_db.c |2 +
>>osaf/libs/agents/saf/cpa/cpa_mds.c|4 +-
>>osaf/libs/agents/saf/cpa/cpa_proc.c |2 +-
>>osaf/libs/common/cpsv/cpsv_evt.c | 440
> ++---
>>osaf/libs/common/cpsv/include/cpa.h |1 +
>>osaf/libs/common/cpsv/include/cpa_cb.h|2 +-
>>osaf/libs/common/cpsv/include/cpa_proc.h |2 +-
>>osaf/libs/common/cpsv/include/cpd.h |1 +
>>osaf/libs/common/cpsv/include/cpd_cb.h| 17 +-
>>osaf/libs/common/cpsv/include/cpd_imm.h |4 +-
>>osaf/libs/common/cpsv/include/cpd_mem.h | 25 +++-
>>osaf/libs/common/cpsv/include/cpd_proc.h |2 +-
>>osaf/libs/common/cpsv/include/cpnd.h |1 +
>>osaf/libs/common/cpsv/include/cpnd_cb.h |5 +-
>>osaf/libs/common/cpsv/include/cpnd_init.h |3 +-
>>osaf/libs/common/cpsv/include/cpsv_evt.h | 10 +
>>osaf/libs/common/cpsv/include/cpsv_shm.h | 24 +++-
>>osaf/services/saf/cpsv/cpd/Makefile.am|1 +
>>osaf/services/saf/cpsv/cpd/cpd_amf.c |7 +-
>>osaf/services/saf/cpsv/cpd/cpd_db.c | 95 +++---
>>osaf/services/saf/cpsv/cpd/cpd_evt.c | 103 ++-
>>osaf/services/saf/cpsv/cpd/cpd_imm.c | 268
> ++
>>osaf/services/saf/cpsv
[devel] Review Request for amf: update PR doc for long DN support [#1642]
Summary: amf: update PR doc for long DN support [#1642] Review request for Trac Ticket(s): #1642 Peer Reviewer(s): AMF devs Pull request to: AMF maintainers Affected branch(es): default Development branch: default Impacted area Impact y/n Docsy Build systemn RPM/packaging n Configuration files n Startup scripts n SAF servicesn OpenSAF servicesn Core libraries n Samples n Tests n Other n Comments (indicate scope for each "y" above): - <> amf: update PR doc for long DN support [#1642] 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_AMF_PR.odt Description: application/vnd.oasis.opendocument.text -- ___ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]
Hi Mahesh,
Please see response below with [HansN]
/Thanks HansN
-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com]
Sent: den 23 augusti 2016 08:25
To: Hans Nordebäck ; Anders Widell
; mathi.naic...@oracle.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]
Hi HansN
Please see response below with [AVM]
-AVM
On 8/23/2016 11:41 AM, Hans Nordebäck wrote:
> Hi Mahesh,
>
> please see comments below.
>
> /Thanks HansN
>
>
> On 08/23/2016 07:21 AM, A V Mahesh wrote:
>> Hi HansN,
>>
>> Let us fist discuss the error handling and abort, then we can come
>> back to interpretation of TIPC currently does permit OR does not
>> permit an application to send a multicast message with the
>> "destination droppable" setting disabled.
>>
>> Let us disable TIPC_DEST_DROPPABLE, so that TIPC will try to return
>> an undelivered multicast message to its sender and we can determine
>> issue is because of TIPC_ERR_OVERLOAD, this helps in debugging , so
>> that application may increased SO_SNDBUF/SO_RCVBUF to reduce the
>> problem.
>>
>> But still we need to abort(), the reason for that is current MDS
>> implementations doesn't have flow control logic ( no retry because of
>> error ) , so Application like AMF can go wrong and cluster will go
>> into unstable/recoverble state.
>>
> [HansN] In the current implementation messages are dropped silently
> and no abort is done.
[AVM] I can see abort(); in current code , you mean abort(); is not working
and application(amf) is not existing ?
[HansN] In case of TIPC_DROPPABLE=true and messages are dropped,
(TIPC_ERR_OVERLOAD) no abort is be performed, e.g
amfd detects this in the msg sanity chk and logs "invalid msg id ..."
if (anc->cmsg_type == TIPC_ERRINFO) {
/* TIPC_ERRINFO - TIPC error code associated with a returned data message
or a connection termination message so abort */
m_MDS_LOG_CRITICAL("MDTM: undelivered message condition ancillary
data: TIPC_ERRINFO abort err :%s", strerror(errno) );
*abort();*
} else if (anc->cmsg_type == TIPC_RETDATA) {
/* If we set TIPC_DEST_DROPPABLE off messge (configure TIPC to return
rejected messages to the sender )
we will hit this when we implement MDS retransmit lost messages abort
can be replaced with flow control logic*/
for (i = anc->cmsg_len - sizeof(*anc); i > 0; i--) {
m_MDS_LOG_DBG("MDTM: returned byte 0x%02x\n", *cptr);
cptr++;
}
/* TIPC_RETDATA -The contents of a returned data message so abort */
m_MDS_LOG_CRITICAL("MDTM: undelivered message condition ancillary
data: TIPC_RETDATA abort err :%s", strerror(errno) );
*abort();*
}
> This patch enables logging
> when packages are dropped to help in debugging. I don't agree that we
> should also introduce abort, but instead:
> 1) Implement a solution to handle dropped packages, ticket #1960
[AVM] This is nothing but flow control implementation in MDS, this is future
enhancement
> 2) Investigate why packages may be dropped, the receiving MDS thread
> is a real time thread and should be able to consume a large amount of
> incoming messages.
> E.g. is the receiving MDS thread "live hanging" due to locks, file I/O
> etc?
>> This was the reason we haven't gone for it while addressing Ticket
>> #1227 (https://sourceforge.net/p/opensaf/mailman/message/33207717/)
>> So currently we don't have any advantage of disabling
>> TIPC_DEST_DROPPABLE and not allowing multicast messages.
>>
>> -AVM
>>
>>
>> On 8/18/2016 2:43 PM, Hans Nordeback wrote:
>>> osaf/libs/core/mds/mds_dt_tipc.c | 32
>>> +---
>>> 1 files changed, 25 insertions(+), 7 deletions(-)
>>>
>>>
>>> diff --git a/osaf/libs/core/mds/mds_dt_tipc.c
>>> b/osaf/libs/core/mds/mds_dt_tipc.c
>>> --- a/osaf/libs/core/mds/mds_dt_tipc.c
>>> +++ b/osaf/libs/core/mds/mds_dt_tipc.c
>>> @@ -320,6 +320,15 @@ uint32_t mdtm_tipc_init(NODE_ID nodeid,
>>> m_MDS_LOG_INFO("MDTM: Successfully set default
>>> socket option TIPC_IMP = %d", TIPCIMPORTANCE);
>>> }
>>> +int droppable = 0;
>>> +if (setsockopt(tipc_cb.BSRsock, SOL_TIPC,
>>> TIPC_DEST_DROPPABLE, &droppable, sizeof(droppable)) != 0) {
>>> +LOG_ER("MDTM: Can't set TIPC_DEST_DROPPABLE to zero
>>> err :%s\n", strerror(errno));
>>> +m_MDS_LOG_ERR("MDTM: Can't set TIPC_DEST_DROPPABLE
>>> to zero err :%s\n", strerror(errno));
>>> +osafassert(0);
>>> +} else {
>>> +m_MDS_LOG_NOTIFY("MDTM: Successfully set
>>> TIPC_DEST_DROPPABLE to zero");
>>> +}
>>> +
>>> return NCSCC_RC_SUCCESS;
>>> }
>>> @@ -563,6 +572,8 @@ ssize_t recvfrom_connectionless (int sd,
>>> unsigned char *cptr;
>>> int i;
>>> int has_
Re: [devel] [PATCH 1 of 1] amfa: fixed freeing notification buff [#1642]
Hi Praveen,
Agree this discussion should be continued, currently it causes a leak.
Thanks,
Minh
On 23/08/16 16:57, praveen malviya wrote:
> Hi Minh,
>
> I am going through the agent code to see if something can be done. I
> think, since B.04.01 APIs are not implemented this problem is coming.
> But still all longdn patches can be pushed and this discussion can
> continue.
>
> What do you think?
>
>
> Thanks,
> praveen
>
>
>
> On 22-Aug-16 12:08 PM, minh chau wrote:
>> Hi Praveen,
>>
>> The case you just mentioned is still in callback context, so Agent can
>> help application to release the allocated notification. But still
>> another case:
>>
>> +SaAmfProtectionGroupNotificationBufferT buff;
>> +buff.notification = NULL;
>> +rc = saAmfProtectionGroupTrack_4(my_amf_hdl, &track_csi,
>> SA_TRACK_CURRENT, &buff);
>> +if (rc != SA_AIS_OK) {
>> +syslog(LOG_ERR, "saAmfProtectionGroupTrack FAILED - %u", rc);
>> +goto done;
>> +}
>>
>> In this case Agent has to allocate notification but it's not in Agent's
>> context.
>> Application has to call API Free_4(buff.notification) to free up
>> notification.
>> In order to iterate to free longDn(s) inside Free_4(), Agent has to
>> memorize a list numberOfItems for every single call as above Track_4(),
>> or Agent can add sentinel element to the allocated notification.
>>
>> Thanks,
>> Minh
>>
>> On 22/08/16 15:34, praveen malviya wrote:
>>> Hi,
>>> The callback looks like this:
>>> typedef void
>>> (*SaAmfProtectionGroupTrackCallbackT_4)(
>>> const SaNameT *csiName,
>>> SaAmfProtectionGroupNotificationBufferT_4 *notificationBuffer,
>>> SaUint32T numberOfMembers,
>>> SaAisErrorT error);
>>>
>>> Inside this callback, application is supposed to call
>>> saAmfProtectionGroupNotificationFree_4(). So agent must be able to
>>> deduce this information as SaAmfProtectionGroupNotificationBufferT_4
>>> contains numberOfItems and also numberOfMembers is available from
>>> callback.
>>> Since B.04.01 APIs are not fully implemented, agent copies from old
>>> type of structure to new type in ava_cpy_protection_group_ntf().
>>>
>>>
>>> Thanks,
>>> Praveen
>>>
>>> On 22-Aug-16 10:51 AM, minh chau wrote:
Hi Praveen,
The problem with B.04.01 is the API:
saAmfProtectionGroupNotificationFree_4(SaAmfHandleT hdl,
SaAmfProtectionGroupNotificationT_4 *notification) does not have
numberOfItems.
Agent does not know how many element in *notification, each of element
can hide a longDn inside it.
Thanks,
Minh
On 22/08/16 15:04, praveen malviya wrote:
> Hi Minh,
>
> SaAmfProtectionGroupNotificationBufferT_4() contains numberOfItems to
> iterate over. In case of B.04.01, it should be simple as agent can
> call direclty osaf_extended_name_free() during iteration inside
> saAmfProtectionGroupNotificationFree_4(). So I think, only a for loop
> which will iterate over numberOfItems is required.
>
> Problem was in B.01.01 case, where application will have to iterate
> and free the memory. For this, Long has already suggested and that
> needs to be documented.
>
>
> Thanks,
> Praveen
>
>
> On 20-Aug-16 2:22 PM, minh chau wrote:
>> Hi Long, Praveen,
>>
>> Regarding this TODO
>> + if(notification) {
>> +// TODO (minhchau): memleak if notification is an array
>> + osaf_extended_name_free(¬ification->member.compName);
>> free(notification);
>> + }
>>
>> Client currently uses saAmfProtectionGroupNotificationFree_4(handle,
>> buff->notification) to free the notification in buffer.
>> If @buff->notification is a list of shortDn only, that should
>> work as
>> before, as agent will call this inside
>> saAmfProtectionGroupNotificationFree_4
>>
>> /* free memory */
>> if(notification)
>> free(notification);
>>
>> It will cause memory leak if @buff->notification contains a list of
>> longDN notifications.
>> The leak is longDn of compName in each notification after the the
>> first
>> one in the array @buff->notification.
>>
>> Agent can add a sentinel element when agent allocates
>> @buff->notification, set this last element as NULL
>> In Free() API, agent could iterate and free longDn in each
>> element of
>> array @buff->notification until agent reaches NULL element.
>>
>> Do you think it could work?
>
>>
>> Thanks,
>> Minh
>>
>> On 19/08/16 21:13, Long Nguyen wrote:
>>> Hi Praveen,
>>>
>>> Please see my answers marked with [Long].
>>>
>>> Best regards,
>>> Long Nguyen.
>>>
>>> On 8/19/2016 6:01 PM, praveen malviya wrote:
Hi Long,
I see one problem if B.01.01 application frees the memory in pg
tracking callback.
Please see inline.
Thanks,
[devel] [PATCH 0 of 1] Review Request for ckpt: fix cppcheck warning [#1874] v2
Summary: ckpt: fix cppcheck warning [#1874] Review request for Trac Ticket(s): 1874 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 a617a2382fd106b1748a483c746caf6a4d264dce Author: Hoang Vo Date: Tue, 23 Aug 2016 15:28:09 +0700 ckpt: fix cppcheck warning [#1874] v2 This enhancement fix following warning results from cppcheck 1.74: Either the condition is redundant or there is possible null pointer dereference This enhancement does not fix following warnings when they are not problems: Possible null pointer dereference Style and performance warnings Complete diffstat: -- osaf/services/saf/cpsv/cpd/cpd_db.c | 8 +++- osaf/services/saf/cpsv/cpd/cpd_evt.c| 4 ++-- osaf/services/saf/cpsv/cpd/cpd_imm.c| 2 +- osaf/services/saf/cpsv/cpd/cpd_tmr.c| 2 +- osaf/services/saf/cpsv/cpnd/cpnd_evt.c | 49 - osaf/services/saf/cpsv/cpnd/cpnd_proc.c | 2 +- 6 files changed, 32 insertions(+), 35 deletions(-) Testing Commands: - Run osaftest cases on cpsv Testing, Expected Results: -- All test cases passed 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
[devel] [PATCH 1 of 1] ckpt: fix cppcheck warning [#1874] v2
osaf/services/saf/cpsv/cpd/cpd_db.c | 8 ++---
osaf/services/saf/cpsv/cpd/cpd_evt.c| 4 +-
osaf/services/saf/cpsv/cpd/cpd_imm.c| 2 +-
osaf/services/saf/cpsv/cpd/cpd_tmr.c| 2 +-
osaf/services/saf/cpsv/cpnd/cpnd_evt.c | 49
osaf/services/saf/cpsv/cpnd/cpnd_proc.c | 2 +-
6 files changed, 32 insertions(+), 35 deletions(-)
This enhancement fix following warning results from cppcheck 1.74:
Either the condition is redundant or there is possible null pointer dereference
This enhancement does not fix following warnings when they are not problems:
Possible null pointer dereference
Style and performance warnings
diff --git a/osaf/services/saf/cpsv/cpd/cpd_db.c
b/osaf/services/saf/cpsv/cpd/cpd_db.c
--- a/osaf/services/saf/cpsv/cpd/cpd_db.c
+++ b/osaf/services/saf/cpsv/cpd/cpd_db.c
@@ -842,12 +842,10 @@ uint32_t cpd_cpnd_info_node_delete(CPD_C
}
/* Free the Client Node */
- if (cpnd_info_node) {
- if (cpnd_info_node->cpnd_ret_timer.uarg)
- ncshm_destroy_hdl(NCS_SERVICE_ID_CPD,
cpnd_info_node->cpnd_ret_timer.uarg);
+ if (cpnd_info_node->cpnd_ret_timer.uarg)
+ ncshm_destroy_hdl(NCS_SERVICE_ID_CPD,
cpnd_info_node->cpnd_ret_timer.uarg);
- m_MMGR_FREE_CPD_CPND_INFO_NODE(cpnd_info_node);
- }
+ m_MMGR_FREE_CPD_CPND_INFO_NODE(cpnd_info_node);
return rc;
diff --git a/osaf/services/saf/cpsv/cpd/cpd_evt.c
b/osaf/services/saf/cpsv/cpd/cpd_evt.c
--- a/osaf/services/saf/cpsv/cpd/cpd_evt.c
+++ b/osaf/services/saf/cpsv/cpd/cpd_evt.c
@@ -1434,7 +1434,7 @@ static uint32_t cpd_evt_proc_mds_evt(CPD
/* No Checkpoints on this node, */
TRACE_LEAVE();
return NCSCC_RC_SUCCESS;
- } else if (node_info &&
(node_info->ckpt_ref_list == NULL)) {
+ } else if (node_info->ckpt_ref_list == NULL) {
cpd_cpnd_info_node_delete(cb,
node_info);
TRACE_LEAVE();
return NCSCC_RC_SUCCESS;
@@ -1448,7 +1448,7 @@ static uint32_t cpd_evt_proc_mds_evt(CPD
/* No Checkpoints on this node, */
return NCSCC_RC_SUCCESS;
}
- else if (node_info && (node_info->ckpt_ref_list
== NULL)) {
+ else if (node_info->ckpt_ref_list == NULL) {
cpd_cpnd_info_node_delete(cb,
node_info);
TRACE_LEAVE();
return NCSCC_RC_SUCCESS;
diff --git a/osaf/services/saf/cpsv/cpd/cpd_imm.c
b/osaf/services/saf/cpsv/cpd/cpd_imm.c
--- a/osaf/services/saf/cpsv/cpd/cpd_imm.c
+++ b/osaf/services/saf/cpsv/cpd/cpd_imm.c
@@ -1014,7 +1014,7 @@ SaUint32T cpd_get_scAbsenceAllowed_attr(
/* Handle the global scAbsenceAllowed_flag */
attribute = attributes[0];
- TRACE("%s attrName \"%s\"",__FUNCTION__,attribute->attrName);
+ TRACE("%s attrName
\"%s\"",__FUNCTION__,attribute?attribute->attrName:"");
if ((attribute != NULL) && (attribute->attrValuesNumber != 0)) {
/* scAbsenceAllowed has value. Get the value */
value = attribute->attrValues[0];
diff --git a/osaf/services/saf/cpsv/cpd/cpd_tmr.c
b/osaf/services/saf/cpsv/cpd/cpd_tmr.c
--- a/osaf/services/saf/cpsv/cpd/cpd_tmr.c
+++ b/osaf/services/saf/cpsv/cpd/cpd_tmr.c
@@ -42,7 +42,7 @@ void cpd_timer_expiry(NCSCONTEXT uarg)
CPSV_EVT *evt = NULL;
uint32_t cpd_hdl = m_CPD_GET_CB_HDL;
- TRACE("cpd_timer_expiry(uarg=%p, type=%u)", uarg, tmr->type);
+ TRACE("cpd_timer_expiry(uarg=%p, type=%u)", uarg, tmr ? tmr->type : 0);
/* post a message to the corresponding component */
if ((cb = (CPD_CB *)ncshm_take_hdl(NCS_SERVICE_ID_CPD, cpd_hdl)) ==
NULL)
diff --git a/osaf/services/saf/cpsv/cpnd/cpnd_evt.c
b/osaf/services/saf/cpsv/cpnd/cpnd_evt.c
--- a/osaf/services/saf/cpsv/cpnd/cpnd_evt.c
+++ b/osaf/services/saf/cpsv/cpnd/cpnd_evt.c
@@ -759,7 +759,7 @@ static uint32_t cpnd_evt_proc_ckpt_open(
send_evt.info.cpa.info.openRsp.error = SA_AIS_ERR_NO_MEMORY;
goto agent_rsp;
}
- if (out_evt && out_evt->info.cpnd.info.ckpt_info.error != SA_AIS_OK) {
+ if (out_evt->info.cpnd.info.ckpt_info.error != SA_AIS_OK) {
send_evt.info.cpa.info.openRsp.error =
out_evt->info.cpnd.info.ckpt_info.error;
goto agent_rsp;
}
@@ -872,10 +872,8 @@ static uint32_t cpnd_evt_proc_ckpt_open(
goto ckpt_shm_node_free_error;
}
}
- if (out_evt) {
-
[devel] [PATCH 1 of 1] smfd: Merge rolling to singlestep procedures for several nodes [#1685]
osaf/services/saf/smfsv/config/smfsv_classes.xml| 13 +
osaf/services/saf/smfsv/smfd/Makefile.am|6 +-
osaf/services/saf/smfsv/smfd/SmfCampState.cc| 125 +-
osaf/services/saf/smfsv/smfd/SmfCampaign.cc | 78 ++-
osaf/services/saf/smfsv/smfd/SmfCampaign.hh |1 +
osaf/services/saf/smfsv/smfd/SmfExecControl.cc | 399
osaf/services/saf/smfsv/smfd/SmfExecControl.h | 56 ++
osaf/services/saf/smfsv/smfd/SmfProcState.cc|7 +-
osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc | 32 +-
osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.hh | 24 +-
osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc | 14 +-
osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh | 20 +-
osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh | 13 +-
osaf/services/saf/smfsv/smfd/smfd.h |2 +-
14 files changed, 605 insertions(+), 185 deletions(-)
diff --git a/osaf/services/saf/smfsv/config/smfsv_classes.xml
b/osaf/services/saf/smfsv/config/smfsv_classes.xml
--- a/osaf/services/saf/smfsv/config/smfsv_classes.xml
+++ b/osaf/services/saf/smfsv/config/smfsv_classes.xml
@@ -531,5 +531,18 @@
SA_WRITABLE
0
+
+ numberOfSingleSteps
+ SA_UINT32_T
+ SA_CONFIG
+ SA_WRITABLE
+
+
+ nodesForSingleStep
+ SA_STRING_T
+ SA_CONFIG
+ SA_WRITABLE
+ SA_MULTI_VALUE
+
diff --git a/osaf/services/saf/smfsv/smfd/Makefile.am
b/osaf/services/saf/smfsv/smfd/Makefile.am
--- a/osaf/services/saf/smfsv/smfd/Makefile.am
+++ b/osaf/services/saf/smfsv/smfd/Makefile.am
@@ -49,7 +49,8 @@ noinst_HEADERS = \
SmfCampaignWrapup.hh \
SmfCampaignInit.hh \
SmfCallback.hh \
- SmfCbkUtil.hh
+ SmfCbkUtil.hh \
+ SmfExecControl.h
osafsmfd_CXXFLAGS = $(AM_CXXFLAGS) @XML2_CFLAGS@
@@ -87,7 +88,8 @@ osafsmfd_SOURCES = \
SmfCampaignInit.cc \
SmfCampaignWrapup.cc \
SmfCallback.cc \
- SmfCbkUtil.cc
+ SmfCbkUtil.cc \
+ SmfExecControl.cc
osafsmfd_LDFLAGS = \
$(AM_LDFLAGS) \
diff --git a/osaf/services/saf/smfsv/smfd/SmfCampState.cc
b/osaf/services/saf/smfsv/smfd/SmfCampState.cc
--- a/osaf/services/saf/smfsv/smfd/SmfCampState.cc
+++ b/osaf/services/saf/smfsv/smfd/SmfCampState.cc
@@ -32,6 +32,7 @@
#include "SmfCampaignThread.hh"
#include "SmfCampaign.hh"
#include "SmfProcedureThread.hh"
+#include "smfsv_defs.h"
#include
#include
/*
@@ -764,12 +765,7 @@ SmfCampStateExecuting::execute(SmfUpgrad
//must be restarted. The execution shall continue at step execution
phase. The procedure initialization
//and step calculation was performed before the move of control.
-std::vector < SmfUpgradeProcedure * > procedures;
-if (i_camp->getProcExecutionMode() == SMF_MERGE_TO_SINGLE_STEP) {
-procedures.push_back(i_camp->getMergedProc());
-} else {
-procedures = i_camp->getProcedures();
-}
+std::vector procedures = i_camp->getProcedures();
std::vector < SmfUpgradeProcedure * >::iterator iter;
bool execProcFound = false;
@@ -817,13 +813,7 @@ SmfCampStateExecuting::executeProc(SmfUp
//The procedure vector is sorted in execution level order (low -> high)
//Lowest number shall be executed first.
-std::vector < SmfUpgradeProcedure * > procedures;
-if (i_camp->getProcExecutionMode() == SMF_MERGE_TO_SINGLE_STEP) {
-procedures.push_back(i_camp->getMergedProc());
-} else {
-procedures = i_camp->getProcedures();
-}
-
+std::vector procedures = i_camp->getProcedures();
std::vector < SmfUpgradeProcedure * >::iterator iter;
int execLevel = -1;
@@ -912,12 +902,7 @@ SmfCampStateExecuting::suspend(SmfUpgrad
TRACE("SmfCampStateExecuting::suspend implementation");
/* Send suspend message to all procedures */
-std::vector < SmfUpgradeProcedure * > procedures;
-if (i_camp->getProcExecutionMode() == SMF_MERGE_TO_SINGLE_STEP) {
-procedures.push_back(i_camp->getMergedProc());
-} else {
-procedures = i_camp->getProcedures();
-}
+std::vector procedures = i_camp->getProcedures();
std::vector < SmfUpgradeProcedure * >::iterator iter;
@@ -966,12 +951,7 @@ SmfCampStateExecuting::procResult(SmfUpg
LOG_NO("CAMP: Procedure %s returned STEPUNDONE",
i_procedure->getProcName().c_str());
/* Send suspend message to all procedures */
-std::vector < SmfUpgradeProcedure
[devel] [PATCH 0 of 1] Review Request for smfd: Merge rolling to singlestep procedures for several nodes [#1685]
Summary: smfd: Merge rolling to singlestep procedures for several nodes Review request for Trac Ticket(s): #1685 Peer Reviewer(s): lennart, reddy Pull request to: <> Affected branch(es): <> Development branch: <> Impacted area Impact y/n Docsn Build systemn RPM/packaging n Configuration files n Startup scripts n SAF servicesy OpenSAF servicesn Core libraries n Samples n Tests n Other n Comments (indicate scope for each "y" above): - Still missing: si-swap handling to be added oi for openSafSmfExecControl to be added changeset 95f9f432c9d79c29a2ba971add5ad490f28ca0a3 Author: Rafael Odzakow Date: Tue, 23 Aug 2016 10:02:51 +0200 smfd: Merge rolling to singlestep procedures for several nodes [#1685] This commit enables the balanced mode feature. This mode changes the execution of rolling procedures to be merged into one or several single steps that are spread out across the cluster nodes. This feature is used to give a faster upgrade time compared to rolling procedures upgrading one node at a time, possibly several times for each node. By splittting the procedures it into several single steps across the nodes a total service outage can be avoided. Added Files: osaf/services/saf/smfsv/smfd/SmfExecControl.cc osaf/services/saf/smfsv/smfd/SmfExecControl.h Complete diffstat: -- osaf/services/saf/smfsv/config/smfsv_classes.xml| 13 + osaf/services/saf/smfsv/smfd/Makefile.am|6 +- osaf/services/saf/smfsv/smfd/SmfCampState.cc| 125 --- osaf/services/saf/smfsv/smfd/SmfCampaign.cc | 78 -- osaf/services/saf/smfsv/smfd/SmfCampaign.hh |1 + osaf/services/saf/smfsv/smfd/SmfExecControl.cc | 399 +++ osaf/services/saf/smfsv/smfd/SmfExecControl.h | 56 + osaf/services/saf/smfsv/smfd/SmfProcState.cc|7 ++- osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.cc | 32 -- osaf/services/saf/smfsv/smfd/SmfUpgradeCampaign.hh | 24 -- osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.cc | 14 -- osaf/services/saf/smfsv/smfd/SmfUpgradeProcedure.hh | 20 +++- osaf/services/saf/smfsv/smfd/SmfUpgradeStep.hh | 13 ++--- osaf/services/saf/smfsv/smfd/smfd.h |2 +- 14 files changed, 605 insertions(+), 185 deletions(-) Testing Commands: - Campaign with rolling procedures is attached to the ticket. Run a campaign with rolling procedures on payloads and enable the balanced mode: immcfg -c OpenSafSmfExecControl -a procExecMode=2 openSafSmfExecControl=MergeCampToSS2 immcfg -a numberOfSingleSteps=2 -a nodesForSingleStep=PL-3 -a nodesForSingleStep=PL-4 openSafSmfExecControl=MergeCampToSS2 immcfg -a openSafSmfExecControl=openSafSmfExecControl=MergeCampToSS2 smfConfig=1,safApp=safSmfService In this configuration we can expect to run one single step procedures on each of the payloads specified. Testing, Expected Results: -- campaign should have executed all steps according to configuration Conditions of Submission: - <> Arch Built StartedLinux distro --- mipsn n mips64 n n x86 n n x86_64 n n powerpc n n powerpc64 n n Reviewer Checklist: --- [Submitters: make sure that your review doesn't trigger any checkmarks!] Your checkin has not passed review because (see checked entries): ___ Your RR template is generally incomplete; it has too many blank entries that need proper data filled in. ___ You have failed to nominate the proper persons for review and push. ___ Your patches do not have proper short+long header ___ You have grammar/spelling in your header that is unacceptable. ___ You have exceeded a sensible line length in your headers/comments/text. ___ You have failed to put in a proper Trac Ticket # into your commits. ___ You have incorrectly put/left internal data in your comments/files (i.e. internal bug tracking tool IDs, product names etc) ___ You have not given any evidence of testing beyond basic build tests. Demonstrate some level of runtime or other sanity testing. ___ You have ^M present in some of your files. These have to be removed. ___ You have needlessly changed whitespace or added whitespace crimes like trailing spaces, or spaces be
Re: [devel] [PATCH 1 of 1] log: fix failed to recover app streams [#1941]
Hi Vu, In case logRootDirectory is /var/log/opensaf/saflog , and it is available , still getting problem. PL-3:/var/log/opensaf/saflog # /usr/bin/logtest -e 9 Suite 9: LOG Server down / up ; Preparing 8 streams for test. Please wait... Preparing stream 0 ... Preparing stream 1 ... cur_logfile_name_get scandir Fail No such file or directorysaLogRecov_prepare_client1_8streams Internal error. Test failed 2 FAILED (expected EXIT_SUCCESS, got EXIT_FAILURE (1))PL-3:/var/log/opensaf/saflog # /usr/bin/logtest -e 9 Suite 9: LOG Server down / up ; Preparing 8 streams for test. Please wait... Preparing stream 0 ... Preparing stream 1 ... cur_logfile_name_get scandir Fail No such file or directorysaLogRecov_prepare_client1_8streams Internal error. Test failed 2 FAILED (expected EXIT_SUCCESS, got EXIT_FAILURE (1))PL-3:/var/log/opensaf/saflog # pwd /var/log/opensaf/saflog PL-3:/var/log/opensaf/saflog # ls PL-3:/var/log/opensaf/saflog # immlist logConfig=1,safApp=safLogService Name Type Value(s) logStreamSystemLowLimitSA_UINT32_T 0 (0x0) logStreamSystemHighLimit SA_UINT32_T 0 (0x0) logStreamFileFormatSA_STRING_T logStreamAppLowLimit SA_UINT32_T 0 (0x0) logStreamAppHighLimit SA_UINT32_T 0 (0x0) logRootDirectory SA_STRING_T /var/log/opensaf/saflog logMaxLogrecsize SA_UINT32_T 1024 (0x400) logMaxApplicationStreams SA_UINT32_T 64 (0x40) logFileSysConfig SA_UINT32_T 1 (0x1) logFileIoTimeout SA_UINT32_T 500 (0x1f4) logDataGroupname SA_STRING_T logConfig SA_STRING_T logConfig=1 SaImmAttrImplementerName SA_STRING_T safLogService SaImmAttrClassName SA_STRING_T OpenSafLogConfig SaImmAttrAdminOwnerNameSA_STRING_T IMMLOADER -AVM On 8/23/2016 12:50 PM, Vu Minh Nguyen wrote: > Hi Mahesh, > > The folder "/repl_opensaf/saflog/logtest_sc_down_path/" is on UML container. > I guess, on your system, the path is different. > > To get the correct patch to shared log folder, do following: > > 1) Get the log root folder: > # immlist logConfig=1,safApp=safLogService > Name Type Value(s) > > logRootDirectory SA_STRING_T > /repl_opensaf/saflog > > > 2) On PL, check if the node can access to shared folder: > /logtest_sc_down_path > > > Regards, Vu > >> -Original Message- >> From: A V Mahesh [mailto:mahesh.va...@oracle.com] >> Sent: Tuesday, August 23, 2016 1:59 PM >> To: Vu Minh Nguyen ; 'Lennart Lund' >> >> Cc: opensaf-devel@lists.sourceforge.net >> Subject: Re: [devel] [PATCH 1 of 1] log: fix failed to recover app streams >> [#1941] >> >> Hi Vu, >> >> This folder doesn't exist , i just created on PL-3 , still failing >> >> PL-3:~ # mkdir -p /repl_opensaf/saflog/logtest_sc_down_path/ >> PL-3:~ # >> >> PL-3:~ # /usr/bin/logtest -e 9 >> >> Suite 9: LOG Server down / up >> ; >> Preparing 8 streams for test. Please wait... >> Preparing stream 0 >> ... >> Preparing stream 1 >> ... >> cur_logfile_name_get scandir Fail No such file or >> directorysaLogRecov_prepare_client1_8streams Internal error. Test failed >> 2 FAILED (expected EXIT_SUCCESS, got EXIT_FAILURE (1))PL-3:~ # >> >> -AVM >> >> >> On 8/23/2016 12:21 PM, Vu Minh Nguyen wrote: >>> Hi Mahesh, >>> >>> Can you check if PL node can access the shared log folder? >>> >>> E.g: path on UML test >>> /repl_opensaf/saflog/logtest_sc_down_path/ >>> >>> I guess the problem is caused by PL not able to access the SAF log > folder. >>> Regards, Vu >>> -Original Message- From: A V Mahesh [mailto:mahesh.va...@oracle.com] Sent: Tuesday, August 23, 2016 1:46 PM To: Vu Minh Nguyen ; Lennart Lund Cc: opensaf-devel@lists.sourceforge.net Subject: Re: [devel] [PATCH 1 of 1] log: fix failed to recover app > streams [#1941] Hi Vu, I got it running on SC , but it is failing on PL with : "cur_logfile_name_get scandir Fail No such file or directorysaLogRecov_prepare_client1_8streams Internal error. Test > failed 2
Re: [devel] [PATCH 1 of 1] ckpt: fix cppcheck warning [#1874] v2
ACK
-AVM
On 8/23/2016 2:11 PM, Hoang Vo wrote:
> osaf/services/saf/cpsv/cpd/cpd_db.c | 8 ++---
> osaf/services/saf/cpsv/cpd/cpd_evt.c| 4 +-
> osaf/services/saf/cpsv/cpd/cpd_imm.c| 2 +-
> osaf/services/saf/cpsv/cpd/cpd_tmr.c| 2 +-
> osaf/services/saf/cpsv/cpnd/cpnd_evt.c | 49
>
> osaf/services/saf/cpsv/cpnd/cpnd_proc.c | 2 +-
> 6 files changed, 32 insertions(+), 35 deletions(-)
>
>
> This enhancement fix following warning results from cppcheck 1.74:
> Either the condition is redundant or there is possible null pointer
> dereference
>
> This enhancement does not fix following warnings when they are not problems:
> Possible null pointer dereference
> Style and performance warnings
>
> diff --git a/osaf/services/saf/cpsv/cpd/cpd_db.c
> b/osaf/services/saf/cpsv/cpd/cpd_db.c
> --- a/osaf/services/saf/cpsv/cpd/cpd_db.c
> +++ b/osaf/services/saf/cpsv/cpd/cpd_db.c
> @@ -842,12 +842,10 @@ uint32_t cpd_cpnd_info_node_delete(CPD_C
> }
>
> /* Free the Client Node */
> - if (cpnd_info_node) {
> - if (cpnd_info_node->cpnd_ret_timer.uarg)
> - ncshm_destroy_hdl(NCS_SERVICE_ID_CPD,
> cpnd_info_node->cpnd_ret_timer.uarg);
> + if (cpnd_info_node->cpnd_ret_timer.uarg)
> + ncshm_destroy_hdl(NCS_SERVICE_ID_CPD,
> cpnd_info_node->cpnd_ret_timer.uarg);
>
> - m_MMGR_FREE_CPD_CPND_INFO_NODE(cpnd_info_node);
> - }
> + m_MMGR_FREE_CPD_CPND_INFO_NODE(cpnd_info_node);
>
> return rc;
>
> diff --git a/osaf/services/saf/cpsv/cpd/cpd_evt.c
> b/osaf/services/saf/cpsv/cpd/cpd_evt.c
> --- a/osaf/services/saf/cpsv/cpd/cpd_evt.c
> +++ b/osaf/services/saf/cpsv/cpd/cpd_evt.c
> @@ -1434,7 +1434,7 @@ static uint32_t cpd_evt_proc_mds_evt(CPD
> /* No Checkpoints on this node, */
> TRACE_LEAVE();
> return NCSCC_RC_SUCCESS;
> - } else if (node_info &&
> (node_info->ckpt_ref_list == NULL)) {
> + } else if (node_info->ckpt_ref_list == NULL) {
> cpd_cpnd_info_node_delete(cb,
> node_info);
> TRACE_LEAVE();
> return NCSCC_RC_SUCCESS;
> @@ -1448,7 +1448,7 @@ static uint32_t cpd_evt_proc_mds_evt(CPD
> /* No Checkpoints on this node, */
> return NCSCC_RC_SUCCESS;
> }
> - else if (node_info && (node_info->ckpt_ref_list
> == NULL)) {
> + else if (node_info->ckpt_ref_list == NULL) {
> cpd_cpnd_info_node_delete(cb,
> node_info);
> TRACE_LEAVE();
> return NCSCC_RC_SUCCESS;
> diff --git a/osaf/services/saf/cpsv/cpd/cpd_imm.c
> b/osaf/services/saf/cpsv/cpd/cpd_imm.c
> --- a/osaf/services/saf/cpsv/cpd/cpd_imm.c
> +++ b/osaf/services/saf/cpsv/cpd/cpd_imm.c
> @@ -1014,7 +1014,7 @@ SaUint32T cpd_get_scAbsenceAllowed_attr(
>
> /* Handle the global scAbsenceAllowed_flag */
> attribute = attributes[0];
> - TRACE("%s attrName \"%s\"",__FUNCTION__,attribute->attrName);
> + TRACE("%s attrName
> \"%s\"",__FUNCTION__,attribute?attribute->attrName:"");
> if ((attribute != NULL) && (attribute->attrValuesNumber != 0)) {
> /* scAbsenceAllowed has value. Get the value */
> value = attribute->attrValues[0];
> diff --git a/osaf/services/saf/cpsv/cpd/cpd_tmr.c
> b/osaf/services/saf/cpsv/cpd/cpd_tmr.c
> --- a/osaf/services/saf/cpsv/cpd/cpd_tmr.c
> +++ b/osaf/services/saf/cpsv/cpd/cpd_tmr.c
> @@ -42,7 +42,7 @@ void cpd_timer_expiry(NCSCONTEXT uarg)
> CPSV_EVT *evt = NULL;
> uint32_t cpd_hdl = m_CPD_GET_CB_HDL;
>
> - TRACE("cpd_timer_expiry(uarg=%p, type=%u)", uarg, tmr->type);
> + TRACE("cpd_timer_expiry(uarg=%p, type=%u)", uarg, tmr ? tmr->type : 0);
>
> /* post a message to the corresponding component */
> if ((cb = (CPD_CB *)ncshm_take_hdl(NCS_SERVICE_ID_CPD, cpd_hdl)) ==
> NULL)
> diff --git a/osaf/services/saf/cpsv/cpnd/cpnd_evt.c
> b/osaf/services/saf/cpsv/cpnd/cpnd_evt.c
> --- a/osaf/services/saf/cpsv/cpnd/cpnd_evt.c
> +++ b/osaf/services/saf/cpsv/cpnd/cpnd_evt.c
> @@ -759,7 +759,7 @@ static uint32_t cpnd_evt_proc_ckpt_open(
> send_evt.info.cpa.info.openRsp.error = SA_AIS_ERR_NO_MEMORY;
> goto agent_rsp;
> }
> - if (out_evt && out_evt->info.cpnd.info.ckpt_info.error != SA_AIS_OK) {
> + if (out_evt->info.cpnd.info.ckpt_info.error != SA_AIS_OK) {
> send_evt.info.cpa.info.openRsp.error =
> out_evt->info.cpnd.info.ckpt_info.error;
> goto agent_rsp;
> }
> @@ -872,10 +872,8 @@ st
Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]
Hi HansN,
It seems I am missing some thing , please allow me to under stand
If I currently understand you observation :
With current Opensaf code ( this #1957 patch NOT applied ) , by default
TIPC_DROPPABLE=true ,while running Opensaf with that binary
when TIPC_ERR_OVERLOAD occurring, TIPC is not given errors
TIPC_ERRINFO or TIPC_RETDATA and following code is not being get hit
of function recvfrom_connectionless(), is my understanding right ?
=
*if (anc->cmsg_type == TIPC_ERRINFO) {*
/* TIPC_ERRINFO - TIPC error code associated with a returned data
message or a connection termination message so abort */
m_MDS_LOG_CRITICAL("MDTM: undelivered message condition ancillary
data: TIPC_ERRINFO abort err :%s", strerror(errno) );
*abort();*
*} else if (anc->cmsg_type == TIPC_RETDATA) {*
/* If we set TIPC_DEST_DROPPABLE off messge (configure TIPC to
return rejected messages to the sender )
we will hit this when we implement MDS retransmit lost messages
abort can be replaced with flow control logic*/
for (i = anc->cmsg_len - sizeof(*anc); i > 0; i--) {
m_MDS_LOG_DBG("MDTM: returned byte 0x%02x\n", *cptr);
cptr++;
}
/* TIPC_RETDATA -The contents of a returned data message so abort */
m_MDS_LOG_CRITICAL("MDTM: undelivered message condition ancillary
data: TIPC_RETDATA abort err :%s", strerror(errno) );
*abort();*
}
=
-AVM
On 8/23/2016 1:08 PM, Hans Nordebäck wrote:
> Hi Mahesh,
>
> Please see response below with [HansN]
> /Thanks HansN
>
> -Original Message-
> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
> Sent: den 23 augusti 2016 08:25
> To: Hans Nordebäck ; Anders Widell
> ; mathi.naic...@oracle.com
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]
>
> Hi HansN
>
> Please see response below with [AVM]
>
> -AVM
>
> On 8/23/2016 11:41 AM, Hans Nordebäck wrote:
>> Hi Mahesh,
>>
>> please see comments below.
>>
>> /Thanks HansN
>>
>>
>> On 08/23/2016 07:21 AM, A V Mahesh wrote:
>>> Hi HansN,
>>>
>>> Let us fist discuss the error handling and abort, then we can come
>>> back to interpretation of TIPC currently does permit OR does not
>>> permit an application to send a multicast message with the
>>> "destination droppable" setting disabled.
>>>
>>> Let us disable TIPC_DEST_DROPPABLE, so that TIPC will try to return
>>> an undelivered multicast message to its sender and we can determine
>>> issue is because of TIPC_ERR_OVERLOAD, this helps in debugging , so
>>> that application may increased SO_SNDBUF/SO_RCVBUF to reduce the
>>> problem.
>>>
>>> But still we need to abort(), the reason for that is current MDS
>>> implementations doesn't have flow control logic ( no retry because of
>>> error ) , so Application like AMF can go wrong and cluster will go
>>> into unstable/recoverble state.
>>>
>> [HansN] In the current implementation messages are dropped silently
>> and no abort is done.
> [AVM] I can see abort(); in current code , you mean abort(); is not working
> and application(amf) is not existing ?
> [HansN] In case of TIPC_DROPPABLE=true and messages are dropped,
> (TIPC_ERR_OVERLOAD) no abort is be performed, e.g
> amfd detects this in the msg sanity chk and logs "invalid msg id ..."
>
> if (anc->cmsg_type == TIPC_ERRINFO) {
> /* TIPC_ERRINFO - TIPC error code associated with a returned data
> message or a connection termination message so abort */
> m_MDS_LOG_CRITICAL("MDTM: undelivered message condition ancillary
> data: TIPC_ERRINFO abort err :%s", strerror(errno) );
> *abort();*
> } else if (anc->cmsg_type == TIPC_RETDATA) {
> /* If we set TIPC_DEST_DROPPABLE off messge (configure TIPC to return
> rejected messages to the sender )
> we will hit this when we implement MDS retransmit lost messages
> abort can be replaced with flow control logic*/
> for (i = anc->cmsg_len - sizeof(*anc); i > 0; i--) {
> m_MDS_LOG_DBG("MDTM: returned byte 0x%02x\n", *cptr);
> cptr++;
> }
> /* TIPC_RETDATA -The contents of a returned data message so abort */
> m_MDS_LOG_CRITICAL("MDTM: undelivered message condition ancillary
> data: TIPC_RETDATA abort err :%s", strerror(errno) );
> *abort();*
> }
>
>> This patch enables logging
>> when packages are dropped to help in debugging. I don't agree that we
>> should also introduce abort, but instead:
>> 1) Implement a solution to handle dropped packages, ticket #1960
> [AVM] This is nothing but flow control implementation in MDS, this is future
> enhancement
>
>> 2) Investigate why pa
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
Hi Minh,
The following SU lock case is not working. This issue will exist for
all the flows, so please check.
Configuration and traces attached in the ticket.
Steps:
1. Start SC-1, SC-2, PL-3 and PL-4. Run the following command:
immcfg -f /tmp/AppConfig-2N-1725.xml
amf-adm unlock-in safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1
amf-adm unlock-in safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1
amf-adm unlock-in safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1
amf-adm unlock safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1
amf-adm unlock safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1
amf-adm unlock safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1
Assignments are:
PM_SC-1:/home/nagu/views/staging-1725 # /etc/init.d/opensafd status
safSISU=safSu=SC-1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SC-2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=PL-4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=PL-3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SU1\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=ACTIVE(1)
2. Issue lock on SU1.
amf-adm lock safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1
And keep gdb in csi_set callback. Stop SC-1 and SC-2.
Send Ok from csi_set callback.
3. Start SC-1 and SC-2.
4. Assignment to components of SU2 is not given and assignments of SU2 still
shows Standby.
PM_SC-1:/home/nagu/views/staging-1725 # /etc/init.d/opensafd status
safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF
saAmfSISUHAState=STANDBY(2)
safSISU=safSu=SC-1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=PL-4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=PL-3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SC-2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)
safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF
saAmfSISUHAState=ACTIVE(1)
Thanks
-Nagu
> -Original Message-
> From: Minh Hon Chau [mailto:minh.c...@dektech.com.au]
> Sent: 05 August 2016 02:50
> To: hans.nordeb...@ericsson.com; Nagendra Kumar; Praveen Malviya;
> gary@dektech.com.au; long.hb.ngu...@dektech.com.au;
> minh.c...@dektech.com.au
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback
> completes during headless [#1725 part 1] V1
>
> osaf/services/saf/amf/amfnd/di.cc | 199
> +
> osaf/services/saf/amf/amfnd/include/avnd_di.h |1 +
> 2 files changed, 134 insertions(+), 66 deletions(-)
>
>
> The patch buffers susi_resp_msg during headless stage and resend it to
> AMFD after headless.
>
> diff --git a/osaf/services/saf/amf/amfnd/di.cc
> b/osaf/services/saf/amf/amfnd/di.cc
> --- a/osaf/services/saf/amf/amfnd/di.cc
> +++ b/osaf/services/saf/amf/amfnd/di.cc
> @@ -804,11 +804,6 @@ uint32_t avnd_di_susi_resp_send(AVND_CB
> if (cb->term_state ==
> AVND_TERM_STATE_OPENSAF_SHUTDOWN_STARTED)
> return rc;
>
> - if (cb->is_avd_down == true) {
> -m_AVND_SU_ALL_SI_RESET(su);
> - return rc;
> - }
> -
> // should be in assignment pending state to be here
> osafassert(m_AVND_SU_IS_ASSIGN_PEND(su));
>
> @@ -819,64 +814,76 @@ uint32_t avnd_di_susi_resp_send(AVND_CB
> TRACE_ENTER2("Sending Resp su=%s, si=%s, curr_state=%u,
> prv_state=%u", su->name.value, curr_si->name.value,curr_si-
> >curr_state,curr_si->prv_state);
> /* populate the susi resp msg */
> msg.info.avd = new AVSV_DND_MSG();
> -msg.type = AVND_MSG_AVD;
> -msg.info.avd->msg_type = AVSV_N2D_INFO_SU_SI_ASSIGN_MSG;
> -msg.info.avd->msg_info.n2d_su_si_assign.msg_id = ++(cb-
> >snd_msg_id);
> -msg.info.avd->msg_info.n2d_su_si_assign.node_id = cb-
> >node_info.nodeId;
> -if (si) {
> -msg.info.avd->msg_info.n2d_su_si_assign.single_csi =
> -((si->single_csi_add_rem_in_si ==
> AVSV_SUSI_ACT_BASE) ?
> false : true);
> -}
> -TRACE("curr_assign_state '%u'", curr_si->curr_assign_state);
> -msg.info.avd->msg_info.n2d_su_si_ass
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
Please note that it is on change set 7846:31417997c82f and I have applied
patch of ticket #1894.
Thanks
-Nagu
> -Original Message-
> From: Nagendra Kumar
> Sent: 23 August 2016 15:15
> To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya;
> gary@dektech.com.au; long.hb.ngu...@dektech.com.au
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi
> callback completes during headless [#1725 part 1] V1
>
> Hi Minh,
> The following SU lock case is not working. This issue will exist for all
> the flows, so please check.
>
> Configuration and traces attached in the ticket.
>
> Steps:
> 1. Start SC-1, SC-2, PL-3 and PL-4. Run the following command:
> immcfg -f /tmp/AppConfig-2N-1725.xml
> amf-adm unlock-in safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1
> amf-adm unlock-in safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1
> amf-adm unlock-in safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1
> amf-adm unlock safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1
> amf-adm unlock safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1
> amf-adm unlock safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1
>
> Assignments are:
> PM_SC-1:/home/nagu/views/staging-1725 # /etc/init.d/opensafd status
> safSISU=safSu=SC-
> 1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF
> saAmfSISUHAState=ACTIVE(1)
> safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC-
> 2N,safApp=OpenSAF
> saAmfSISUHAState=ACTIVE(1)
> safSISU=safSu=SC-
> 2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF
> saAmfSISUHAState=ACTIVE(1)
> safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC-
> 2N,safApp=OpenSAF
> saAmfSISUHAState=STANDBY(2)
> safSISU=safSu=PL-
> 4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF
> saAmfSISUHAState=ACTIVE(1)
> safSISU=safSu=PL-
> 3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF
> saAmfSISUHAState=ACTIVE(1)
> safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe
> mo1,safApp=AmfDemo1
> saAmfSISUHAState=STANDBY(2)
> safSISU=safSu=SU1\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe
> mo1,safApp=AmfDemo1
> saAmfSISUHAState=ACTIVE(1)
>
> 2. Issue lock on SU1.
> amf-adm lock safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1
> And keep gdb in csi_set callback. Stop SC-1 and SC-2.
> Send Ok from csi_set callback.
>
> 3. Start SC-1 and SC-2.
>
> 4. Assignment to components of SU2 is not given and assignments of SU2
> still shows Standby.
> PM_SC-1:/home/nagu/views/staging-1725 # /etc/init.d/opensafd status
> safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe
> mo1,safApp=AmfDemo1
> saAmfSISUHAState=STANDBY(2)
> safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC-
> 2N,safApp=OpenSAF
> saAmfSISUHAState=STANDBY(2)
> safSISU=safSu=SC-
> 1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF
> saAmfSISUHAState=ACTIVE(1)
> safSISU=safSu=PL-
> 4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF
> saAmfSISUHAState=ACTIVE(1)
> safSISU=safSu=PL-
> 3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF
> saAmfSISUHAState=ACTIVE(1)
> safSISU=safSu=SC-
> 2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF
> saAmfSISUHAState=ACTIVE(1)
> safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC-
> 2N,safApp=OpenSAF
> saAmfSISUHAState=ACTIVE(1)
>
>
> Thanks
> -Nagu
>
> > -Original Message-
> > From: Minh Hon Chau [mailto:minh.c...@dektech.com.au]
> > Sent: 05 August 2016 02:50
> > To: hans.nordeb...@ericsson.com; Nagendra Kumar; Praveen Malviya;
> > gary@dektech.com.au; long.hb.ngu...@dektech.com.au;
> > minh.c...@dektech.com.au
> > Cc: opensaf-devel@lists.sourceforge.net
> > Subject: [PATCH 2 of 2] AMFND: Admin operation continuation if csi
> > callback completes during headless [#1725 part 1] V1
> >
> > osaf/services/saf/amf/amfnd/di.cc | 199
> > +--
> --
> > osaf/services/saf/amf/amfnd/include/avnd_di.h |1 +
> > 2 files changed, 134 insertions(+), 66 deletions(-)
> >
> >
> > The patch buffers susi_resp_msg during headless stage and resend it to
> > AMFD after headless.
> >
> > diff --git a/osaf/services/saf/amf/amfnd/di.cc
> > b/osaf/services/saf/amf/amfnd/di.cc
> > --- a/osaf/services/saf/amf/amfnd/di.cc
> > +++ b/osaf/services/saf/amf/amfnd/di.cc
> > @@ -804,11 +804,6 @@ uint32_t avnd_di_susi_resp_send(AVND_CB
> > if (cb->term_state ==
> > AVND_TERM_STATE_OPENSAF_SHUTDOWN_STARTED)
> > return rc;
> >
> > - if (cb->is_avd_down == true) {
> > -m_AVND_SU_ALL_SI_RESET(su);
> > - return rc;
> > - }
> > -
> > // should be in assignment pending state to be here
> > osafassert(m_AVND_SU_IS_ASSIGN_PEND(su));
> >
> > @@ -819,64 +814,76 @@ uint32_t avnd_di_susi_resp_send(AVND_CB
> > TRACE_ENTER2("Sending Resp su=%s, si=%s, curr_state=%u,
> > prv_state=%u", su->name.value, curr_si->name.value,curr_si-
> > >curr_stat
Re: [devel] [PATCH 0 of 2] Review Request for imm: Use high resolution time measurements [#1704]
Hi Hung, Reviewed and tested the patch. Ack from me. Thanks, Zoran -Original Message- From: Hung Nguyen [mailto:hung.d.ngu...@dektech.com.au] Sent: den 5 augusti 2016 10:30 To: Zoran Milinkovic; reddy.neelaka...@oracle.com Cc: opensaf-devel@lists.sourceforge.net Subject: [PATCH 0 of 2] Review Request for imm: Use high resolution time measurements [#1704] Summary: imm: Use high resolution time measurements [#1704] Review request for Trac Ticket(s): 1704 Peer Reviewer(s): Zoran, Neel Pull request to: Affected branch(es): 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 c6fef534a014a6e097cb911a773ba8e0604b0d0f Author: Hung Nguyen Date: Thu, 04 Aug 2016 14:37:14 +0700 imm: Use high resolution time measurements for ImmModel [#1704] Use high resolution time measurements for ImmModel. changeset cdf23b0da009f16c99723f43c7b69b66b7f94eab Author: Hung Nguyen Date: Thu, 04 Aug 2016 15:39:09 +0700 imm: Use high resolution time measurements for IMMND server [#1704] This patch just simply gets rid of time_t and uses timespec instead. For now we don't have the advantages of timespec yet. The interval for immnd_process_evt is still one second, so we can't check for timeout at high frequency. That can be improved in another ticket. Complete diffstat: -- osaf/libs/common/immsv/include/immsv.h |8 osaf/services/saf/immsv/immnd/ImmModel.cc| 132 ++-- osaf/services/saf/immsv/immnd/ImmSearchOp.cc |2 +- osaf/services/saf/immsv/immnd/ImmSearchOp.hh |6 +++--- osaf/services/saf/immsv/immnd/immnd.h| 16 osaf/services/saf/immsv/immnd/immnd_cb.h | 12 ++-- osaf/services/saf/immsv/immnd/immnd_evt.c|9 +++-- osaf/services/saf/immsv/immnd/immnd_main.c | 25 - osaf/services/saf/immsv/immnd/immnd_proc.c | 55 +++ 9 files changed, 122 insertions(+), 143 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 propos
Re: [devel] [PATCH 1 of 1] log: fix failed to recover app streams [#1941]
Hi Mahesh, Seems "/var/log/opensaf/saflog" not shared folder? To check that, create something (e.g: a file ) in that folder, and check whether that file can be seen by all nodes. To pass the test, the log folder has to be seen by all nodes. Regards, Vu > -Original Message- > From: A V Mahesh [mailto:mahesh.va...@oracle.com] > Sent: Tuesday, August 23, 2016 4:04 PM > To: Vu Minh Nguyen ; 'Lennart Lund' > > Cc: opensaf-devel@lists.sourceforge.net > Subject: Re: [devel] [PATCH 1 of 1] log: fix failed to recover app streams > [#1941] > > Hi Vu, > > In case logRootDirectory is /var/log/opensaf/saflog , > and it is available , still getting problem. > > ** > ** > PL-3:/var/log/opensaf/saflog # /usr/bin/logtest -e 9 > > Suite 9: LOG Server down / up > ; > Preparing 8 streams for test. Please wait... > Preparing stream 0 > ... > Preparing stream 1 > ... > cur_logfile_name_get scandir Fail No such file or > directorysaLogRecov_prepare_client1_8streams Internal error. Test failed > 2 FAILED (expected EXIT_SUCCESS, got EXIT_FAILURE > (1))PL-3:/var/log/opensaf/saflog # /usr/bin/logtest -e 9 > > Suite 9: LOG Server down / up > ; > Preparing 8 streams for test. Please wait... > Preparing stream 0 > ... > Preparing stream 1 > ... > cur_logfile_name_get scandir Fail No such file or > directorysaLogRecov_prepare_client1_8streams Internal error. Test failed > 2 FAILED (expected EXIT_SUCCESS, got EXIT_FAILURE > (1))PL-3:/var/log/opensaf/saflog # pwd > /var/log/opensaf/saflog > PL-3:/var/log/opensaf/saflog # ls > PL-3:/var/log/opensaf/saflog # immlist logConfig=1,safApp=safLogService > Name Type Value(s) > == > == > logStreamSystemLowLimitSA_UINT32_T 0 (0x0) > logStreamSystemHighLimit SA_UINT32_T 0 (0x0) > logStreamFileFormatSA_STRING_T > logStreamAppLowLimit SA_UINT32_T 0 (0x0) > logStreamAppHighLimit SA_UINT32_T 0 (0x0) > logRootDirectory SA_STRING_T > /var/log/opensaf/saflog > logMaxLogrecsize SA_UINT32_T 1024 (0x400) > logMaxApplicationStreams SA_UINT32_T 64 (0x40) > logFileSysConfig SA_UINT32_T 1 (0x1) > logFileIoTimeout SA_UINT32_T 500 (0x1f4) > logDataGroupname SA_STRING_T > logConfig SA_STRING_T logConfig=1 > SaImmAttrImplementerName SA_STRING_T > safLogService > SaImmAttrClassName SA_STRING_T > OpenSafLogConfig > SaImmAttrAdminOwnerNameSA_STRING_T IMMLOADER > ** > ** > > > -AVM > > On 8/23/2016 12:50 PM, Vu Minh Nguyen wrote: > > Hi Mahesh, > > > > The folder "/repl_opensaf/saflog/logtest_sc_down_path/" is on UML > container. > > I guess, on your system, the path is different. > > > > To get the correct patch to shared log folder, do following: > > > > 1) Get the log root folder: > > # immlist logConfig=1,safApp=safLogService > > Name Type Value(s) > > > == > == > > logRootDirectory SA_STRING_T > > /repl_opensaf/saflog > > > > > > 2) On PL, check if the node can access to shared folder: > > /logtest_sc_down_path > > > > > > Regards, Vu > > > >> -Original Message- > >> From: A V Mahesh [mailto:mahesh.va...@oracle.com] > >> Sent: Tuesday, August 23, 2016 1:59 PM > >> To: Vu Minh Nguyen ; 'Lennart Lund' > >> > >> Cc: opensaf-devel@lists.sourceforge.net > >> Subject: Re: [devel] [PATCH 1 of 1] log: fix failed to recover app streams > >> [#1941] > >> > >> Hi Vu, > >> > >> This folder doesn't exist , i just created on PL-3 , still failing > >> > >> PL-3:~ # mkdir -p /repl_opensaf/saflog/logtest_sc_down_path/ > >> PL-3:~ # > >> > >> PL-3:~ # /usr/bin/logtest -e 9 > >> > >> Suite 9: LOG Server down / up > >> ; > >> Preparing 8 streams for test. Please wait... > >> Preparing stream 0 > >> ... > >> Preparing stream 1 > >> ... > >> cur_logfile_name_get scandir Fail No such file or > >> directorysaLogRecov_prepare_client1_8streams Internal error. Test failed > >> 2 FAILED (expected EXIT_SUCCESS, got EXIT_FAILURE (1))PL-3:~ # > >> > >> -AVM > >> > >> > >> On 8/23/2016 12:21 PM, Vu Minh Nguyen wrote: > >>> Hi Mahesh, > >>> > >>> C
[devel] [PATCH 0 of 1] Review Request for dtm: Fix cppcheck warnings [#1963]
Summary: dtm: Fix cppcheck warnings [#1963] Review request for Trac Ticket(s): 1963 Peer Reviewer(s): Mahesh Pull request to: Affected branch(es): default(5.1) Development branch: default Impacted area Impact y/n Docsn Build systemn RPM/packaging n Configuration files n Startup scripts n SAF servicesn OpenSAF servicesy Core libraries n Samples n Tests n Other n Comments (indicate scope for each "y" above): - changeset 6477e9169d3bf12024f15300edfcc82cd9114931 Author: Anders Widell Date: Tue, 23 Aug 2016 11:59:08 +0200 dtm: Fix cppcheck warnings [#1963] The following warnings, reported by cppcheck version 1.75, have been fixed: [osaf/services/infrastructure/dtms/dtm/dtm_inter_svc.c:342]: (style) The scope of the variable 'buffer' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_intra.c:95]: (style) The scope of the variable 'servlen' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_intra.c:97]: (style) The scope of the variable 'server_ux_name' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_intra.c:155]: (style) Obsolescent function 'bzero' called. It is recommended to use 'memset' instead. [osaf/services/infrastructure/dtms/dtm/dtm_intra.c:207]: (error) Uninitialized variable: serveraddr [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:139]: (style) The scope of the variable 'del_ptr' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:243]: (style) The scope of the variable 'tmp' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:1836]: (style) The scope of the variable 'local_svc_node' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:710]: (style) Variable 'node_id' is assigned a value that is never used. [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:320]: (error) Memory leak: svc_node [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:512]: (error) Memory leak: subscr_node [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:516]: (error) Memory leak: subscr_info [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:1728]: (error) Memory leak: svc_info [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:1754]: (error) Memory leak: local_svc_info [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:54]: (style) Assignment of function parameter has no effect outside the function. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:74]: (style) The scope of the variable 'optlen' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:423]: (style) The scope of the variable 'err' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:617]: (style) The scope of the variable 'ip_addr_eth' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:720]: (style) The scope of the variable 'mcast_addr_eth' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:812]: (style) The scope of the variable 'mcast_addr_eth' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1428]: (style) The scope of the variable 'numericAddress' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1429]: (style) The scope of the variable 'addrBuffer' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:191]: (error) Uninitialized variable: join_request [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:192]: (error) Uninitialized variable: join_request [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:950]: (error) Uninitialized variable: addr_list [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1014]: (error) Uninitialized variable: maddr [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1015]: (error) Uninitialized variable: maddr [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1144]: (error) Uninitialized variable: maddr [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1145]: (error) Uninitialized variable: maddr [osaf/services/infrastructure/dtms/dtm/dtm_read_config.c:139]: (style) The scope of the variable 'tmp' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_read_config.c:140]: (style) The scope of the variable 'buf' can be reduced.
Re: [devel] [PATCH 1 of 1] log: fix failed to recover app streams [#1941]
Hi Vu, ACK, Add TRACE`s in error return cases -AVM On 8/23/2016 3:29 PM, Vu Minh Nguyen wrote: > Hi Mahesh, > > Seems "/var/log/opensaf/saflog" not shared folder? > > To check that, create something (e.g: a file ) in that folder, and check > whether that file > can be seen by all nodes. > > To pass the test, the log folder has to be seen by all nodes. > > Regards, Vu > >> -Original Message- >> From: A V Mahesh [mailto:mahesh.va...@oracle.com] >> Sent: Tuesday, August 23, 2016 4:04 PM >> To: Vu Minh Nguyen ; 'Lennart Lund' >> >> Cc: opensaf-devel@lists.sourceforge.net >> Subject: Re: [devel] [PATCH 1 of 1] log: fix failed to recover app streams >> [#1941] >> >> Hi Vu, >> >> In case logRootDirectory is /var/log/opensaf/saflog , >> and it is available , still getting problem. >> >> ** >> ** >> PL-3:/var/log/opensaf/saflog # /usr/bin/logtest -e 9 >> >> Suite 9: LOG Server down / up >> ; >> Preparing 8 streams for test. Please wait... >> Preparing stream 0 >> ... >> Preparing stream 1 >> ... >> cur_logfile_name_get scandir Fail No such file or >> directorysaLogRecov_prepare_client1_8streams Internal error. Test failed >> 2 FAILED (expected EXIT_SUCCESS, got EXIT_FAILURE >> (1))PL-3:/var/log/opensaf/saflog # /usr/bin/logtest -e 9 >> >> Suite 9: LOG Server down / up >> ; >> Preparing 8 streams for test. Please wait... >> Preparing stream 0 >> ... >> Preparing stream 1 >> ... >> cur_logfile_name_get scandir Fail No such file or >> directorysaLogRecov_prepare_client1_8streams Internal error. Test failed >> 2 FAILED (expected EXIT_SUCCESS, got EXIT_FAILURE >> (1))PL-3:/var/log/opensaf/saflog # pwd >> /var/log/opensaf/saflog >> PL-3:/var/log/opensaf/saflog # ls >> PL-3:/var/log/opensaf/saflog # immlist logConfig=1,safApp=safLogService >> Name Type Value(s) >> == >> == >> logStreamSystemLowLimitSA_UINT32_T 0 (0x0) >> logStreamSystemHighLimit SA_UINT32_T 0 (0x0) >> logStreamFileFormatSA_STRING_T >> logStreamAppLowLimit SA_UINT32_T 0 (0x0) >> logStreamAppHighLimit SA_UINT32_T 0 (0x0) >> logRootDirectory SA_STRING_T >> /var/log/opensaf/saflog >> logMaxLogrecsize SA_UINT32_T 1024 > (0x400) >> logMaxApplicationStreams SA_UINT32_T 64 (0x40) >> logFileSysConfig SA_UINT32_T 1 (0x1) >> logFileIoTimeout SA_UINT32_T 500 > (0x1f4) >> logDataGroupname SA_STRING_T >> logConfig SA_STRING_T logConfig=1 >> SaImmAttrImplementerName SA_STRING_T >> safLogService >> SaImmAttrClassName SA_STRING_T >> OpenSafLogConfig >> SaImmAttrAdminOwnerNameSA_STRING_T IMMLOADER >> ** >> ** >> >> >> -AVM >> >> On 8/23/2016 12:50 PM, Vu Minh Nguyen wrote: >>> Hi Mahesh, >>> >>> The folder "/repl_opensaf/saflog/logtest_sc_down_path/" is on UML >> container. >>> I guess, on your system, the path is different. >>> >>> To get the correct patch to shared log folder, do following: >>> >>> 1) Get the log root folder: >>> # immlist logConfig=1,safApp=safLogService >>> Name Type Value(s) >>> >> == >> == >>> logRootDirectory SA_STRING_T >>> /repl_opensaf/saflog >>> >>> >>> 2) On PL, check if the node can access to shared folder: >>> /logtest_sc_down_path >>> >>> >>> Regards, Vu >>> -Original Message- From: A V Mahesh [mailto:mahesh.va...@oracle.com] Sent: Tuesday, August 23, 2016 1:59 PM To: Vu Minh Nguyen ; 'Lennart Lund' Cc: opensaf-devel@lists.sourceforge.net Subject: Re: [devel] [PATCH 1 of 1] log: fix failed to recover app > streams [#1941] Hi Vu, This folder doesn't exist , i just created on PL-3 , still failing PL-3:~ # mkdir -p /repl_opensaf/saflog/logtest_sc_down_path/ PL-3:~ # PL-3:~ # /usr/bin/logtest -e 9 Suite 9: LOG Server down / up ; Preparing 8 streams for test. Please wait... Preparing stream 0 ... Preparing stream 1 ... cur_logfile_name_get scandir Fail No such file or directorysaLogRecov_prepare_client1_8streams Internal er
[devel] [PATCH 1 of 1] dtm: Fix cppcheck warnings [#1963]
osaf/services/infrastructure/dtms/dtm/dtm_inter_svc.c|5 +- osaf/services/infrastructure/dtms/dtm/dtm_intra.c| 10 +- osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c| 18 +- osaf/services/infrastructure/dtms/dtm/dtm_main.c | 18 - osaf/services/infrastructure/dtms/dtm/dtm_node.c | 96 -- osaf/services/infrastructure/dtms/dtm/dtm_node_db.c | 94 - osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c | 236 +-- osaf/services/infrastructure/dtms/dtm/dtm_read_config.c | 41 +- osaf/services/infrastructure/dtms/include/dtm.h |3 - osaf/services/infrastructure/dtms/include/dtm_cb.h |2 +- osaf/services/infrastructure/dtms/include/dtm_node.h |2 - 11 files changed, 49 insertions(+), 476 deletions(-) The following warnings, reported by cppcheck version 1.75, have been fixed: [osaf/services/infrastructure/dtms/dtm/dtm_inter_svc.c:342]: (style) The scope of the variable 'buffer' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_intra.c:95]: (style) The scope of the variable 'servlen' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_intra.c:97]: (style) The scope of the variable 'server_ux_name' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_intra.c:155]: (style) Obsolescent function 'bzero' called. It is recommended to use 'memset' instead. [osaf/services/infrastructure/dtms/dtm/dtm_intra.c:207]: (error) Uninitialized variable: serveraddr [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:139]: (style) The scope of the variable 'del_ptr' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:243]: (style) The scope of the variable 'tmp' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:1836]: (style) The scope of the variable 'local_svc_node' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:710]: (style) Variable 'node_id' is assigned a value that is never used. [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:320]: (error) Memory leak: svc_node [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:512]: (error) Memory leak: subscr_node [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:516]: (error) Memory leak: subscr_info [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:1728]: (error) Memory leak: svc_info [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:1754]: (error) Memory leak: local_svc_info [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:54]: (style) Assignment of function parameter has no effect outside the function. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:74]: (style) The scope of the variable 'optlen' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:423]: (style) The scope of the variable 'err' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:617]: (style) The scope of the variable 'ip_addr_eth' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:720]: (style) The scope of the variable 'mcast_addr_eth' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:812]: (style) The scope of the variable 'mcast_addr_eth' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1428]: (style) The scope of the variable 'numericAddress' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1429]: (style) The scope of the variable 'addrBuffer' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:191]: (error) Uninitialized variable: join_request [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:192]: (error) Uninitialized variable: join_request [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:950]: (error) Uninitialized variable: addr_list [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1014]: (error) Uninitialized variable: maddr [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1015]: (error) Uninitialized variable: maddr [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1144]: (error) Uninitialized variable: maddr [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1145]: (error) Uninitialized variable: maddr [osaf/services/infrastructure/dtms/dtm/dtm_read_config.c:139]: (style) The scope of the variable 'tmp' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_read_config.c:140]: (style) The scope of the variable 'buf' can be reduced. [osaf/services/infrastructure/dtms/dtm/dtm_read_config.c:271]: (warning) fscanf() without field width limits can crash with huge input data. [osaf/services/infrastructure/dtms/dtm/dtm_read_config.c:327]: (error) Resource leak: dtm_conf_file [osaf/services/infrastructure/dtms/dtm/dtm_node.c:155]: (style) The function 'add_self_node' is never used. [osaf/services/infrastructure/dtms/dtm/dtm_node.c:230]: (style) The function 'datagram_buff_dump' is never used. [osaf/services/infrastructure/
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
Please consider previous TC as TC #1 TC #2: Same configuration as TC #1. Logs attached in the ticket TC #2. Steps: 1. Same as step #1 of TC #1. 2. After locking SU1, keep delay in avnd_evt_avd_info_su_si_assign_evh and stop SC-1 and SC-2. 3. Start SC-1 and SC-2. SU1 is still in quisced state. Ideally, it should have no assignment and SU3 should have got assignment. safSISU=safSu=SU3\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1 saAmfSISUHAState=STANDBY(2) safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDemo1,safApp=AmfDemo1 saAmfSISUHAState=ACTIVE(1) safSISU=safSu=PL-4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) safSISU=safSu=SC-1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) safSISU=safSu=SC-2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF saAmfSISUHAState=STANDBY(2) safSISU=safSu=PL-3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) After that PL-3 rebooted by the following logs: Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: TIMEOUT receiving AMF health check request, generating core for amfnd Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: Last received healthcheck cnt=82 at Tue Aug 23 15:30:52 2016 Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: Rebooting OpenSAF NodeId = 0 EE Name = No EE Mapped, Reason: AMFND unresponsive, AMFWDOG initiated system reboot, OwnNodeId = 131855, SupervisionTime = 60 Aug 23 15:31:52 PM_PL-3 opensaf_reboot: Rebooting local node; timeout=60 Thanks -Nagu > -Original Message- > From: Nagendra Kumar > Sent: 23 August 2016 15:19 > To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; > gary@dektech.com.au; long.hb.ngu...@dektech.com.au > Cc: opensaf-devel@lists.sourceforge.net > Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi > callback completes during headless [#1725 part 1] V1 > > Please note that it is on change set 7846:31417997c82f and I have applied > patch of ticket #1894. > > Thanks > -Nagu > > -Original Message- > > From: Nagendra Kumar > > Sent: 23 August 2016 15:15 > > To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; > > gary@dektech.com.au; long.hb.ngu...@dektech.com.au > > Cc: opensaf-devel@lists.sourceforge.net > > Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi > > callback completes during headless [#1725 part 1] V1 > > > > Hi Minh, > > The following SU lock case is not working. This issue will exist for > > all the flows, so please check. > > > > Configuration and traces attached in the ticket. > > > > Steps: > > 1. Start SC-1, SC-2, PL-3 and PL-4. Run the following command: > > immcfg -f /tmp/AppConfig-2N-1725.xml > > amf-adm unlock-in safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 > > amf-adm unlock-in safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 > > amf-adm unlock-in safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1 > > amf-adm unlock safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 > > amf-adm unlock safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 > > amf-adm unlock safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1 > > > > Assignments are: > > PM_SC-1:/home/nagu/views/staging-1725 # /etc/init.d/opensafd status > > safSISU=safSu=SC- > > 1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF > > saAmfSISUHAState=ACTIVE(1) > > safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC- > > 2N,safApp=OpenSAF > > saAmfSISUHAState=ACTIVE(1) > > safSISU=safSu=SC- > > 2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF > > saAmfSISUHAState=ACTIVE(1) > > safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC- > > 2N,safApp=OpenSAF > > saAmfSISUHAState=STANDBY(2) > > safSISU=safSu=PL- > > 4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF > > saAmfSISUHAState=ACTIVE(1) > > safSISU=safSu=PL- > > 3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF > > saAmfSISUHAState=ACTIVE(1) > > > safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe > > mo1,safApp=AmfDemo1 > > saAmfSISUHAState=STANDBY(2) > > > safSISU=safSu=SU1\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe > > mo1,safApp=AmfDemo1 > > saAmfSISUHAState=ACTIVE(1) > > > > 2. Issue lock on SU1. > > amf-adm lock safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 > > And keep gdb in csi_set callback. Stop SC-1 and SC-2. > > Send Ok from csi_set callback. > > > > 3. Start SC-1 and SC-2. > > > > 4. Assignment to components of SU2 is not given and assignments of SU2 > > still shows Standby. > > PM_SC-1:/home/nagu/views/staging-1725 # /etc/init.d/opensafd status > > > safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe > > mo1,safApp=AmfDemo1 >
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
Please ignore TC #2, my mistake. Thanks -Nagu > -Original Message- > From: Nagendra Kumar > Sent: 23 August 2016 15:49 > To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; > gary@dektech.com.au; long.hb.ngu...@dektech.com.au > Cc: opensaf-devel@lists.sourceforge.net > Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi > callback completes during headless [#1725 part 1] V1 > > Please consider previous TC as TC #1 > > TC #2: Same configuration as TC #1. Logs attached in the ticket TC #2. > > Steps: > 1. Same as step #1 of TC #1. > 2. After locking SU1, keep delay in avnd_evt_avd_info_su_si_assign_evh and > stop SC-1 and SC-2. > 3. Start SC-1 and SC-2. SU1 is still in quisced state. Ideally, it should > have no > assignment and SU3 should have got assignment. > > safSISU=safSu=SU3\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe > mo1,safApp=AmfDemo1 > saAmfSISUHAState=STANDBY(2) > safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe > mo1,safApp=AmfDemo1 > saAmfSISUHAState=ACTIVE(1) > safSISU=safSu=PL- > 4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF > saAmfSISUHAState=ACTIVE(1) > safSISU=safSu=SC- > 1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF > saAmfSISUHAState=ACTIVE(1) > safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC- > 2N,safApp=OpenSAF > saAmfSISUHAState=ACTIVE(1) > safSISU=safSu=SC- > 2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF > saAmfSISUHAState=ACTIVE(1) > safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC- > 2N,safApp=OpenSAF > saAmfSISUHAState=STANDBY(2) > safSISU=safSu=PL- > 3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF > saAmfSISUHAState=ACTIVE(1) > > After that PL-3 rebooted by the following logs: > Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: TIMEOUT receiving AMF > health check request, generating core for amfnd Aug 23 15:31:52 PM_PL-3 > osafamfwd[18056]: Last received healthcheck cnt=82 at Tue Aug 23 15:30:52 > 2016 Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: Rebooting OpenSAF > NodeId = 0 EE Name = No EE Mapped, Reason: AMFND unresponsive, > AMFWDOG initiated system reboot, OwnNodeId = 131855, SupervisionTime > = 60 Aug 23 15:31:52 PM_PL-3 opensaf_reboot: Rebooting local node; > timeout=60 > > Thanks > -Nagu > > > -Original Message- > > From: Nagendra Kumar > > Sent: 23 August 2016 15:19 > > To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; > > gary@dektech.com.au; long.hb.ngu...@dektech.com.au > > Cc: opensaf-devel@lists.sourceforge.net > > Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi > > callback completes during headless [#1725 part 1] V1 > > > > Please note that it is on change set 7846:31417997c82f and I have > > applied patch of ticket #1894. > > > > Thanks > > -Nagu > > > -Original Message- > > > From: Nagendra Kumar > > > Sent: 23 August 2016 15:15 > > > To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; > > > gary@dektech.com.au; long.hb.ngu...@dektech.com.au > > > Cc: opensaf-devel@lists.sourceforge.net > > > Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if > > > csi callback completes during headless [#1725 part 1] V1 > > > > > > Hi Minh, > > > The following SU lock case is not working. This issue will exist > > > for all the flows, so please check. > > > > > > Configuration and traces attached in the ticket. > > > > > > Steps: > > > 1. Start SC-1, SC-2, PL-3 and PL-4. Run the following command: > > > immcfg -f /tmp/AppConfig-2N-1725.xml amf-adm unlock-in > > > safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 > > > amf-adm unlock-in safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 > > > amf-adm unlock-in safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1 > > > amf-adm unlock safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 > > > amf-adm unlock safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 > > > amf-adm unlock safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1 > > > > > > Assignments are: > > > PM_SC-1:/home/nagu/views/staging-1725 # /etc/init.d/opensafd status > > > safSISU=safSu=SC- > > > 1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF > > > saAmfSISUHAState=ACTIVE(1) > > > safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC- > > > 2N,safApp=OpenSAF > > > saAmfSISUHAState=ACTIVE(1) > > > safSISU=safSu=SC- > > > 2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF > > > saAmfSISUHAState=ACTIVE(1) > > > safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC- > > > 2N,safApp=OpenSAF > > > saAmfSISUHAState=STANDBY(2) > > > safSISU=safSu=PL- > > > 4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF > > > saAmfSISUHAState=ACTIVE(1) > > > safSISU=safSu=PL- > > > 3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF > > > saAmfSISUHAState=ACTIVE(1) > > > > > > safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe > > > mo1,safApp=AmfDemo1 > > >
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
Hi Nagu, Please use the patches attached to ticket to test, there are many changes from the version you are testing. https://sourceforge.net/p/opensaf/tickets/_discuss/thread/7b203666/ad7f/attachment/1725_phase_1.tgz It's a rebased longDN version, so you will not have to tested again I just tested the rebased longDN version, it works for me. 2016-08-23 20:19:25 PL-3 osafimmnd[400]: NO Implementer connected: 20 (safSmfService) <0, 2010f> *2016-08-23 20:19:26 PL-3 osafamfnd[421]: NO Found and resend buffered su_si_assign msg for SU:'safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1', SI:'', ha_state:'3', msg_act:'5', single_csi:'0', error:'1', msg_id:'2'* 2016-08-23 20:19:26 PL-3 osafamfnd[421]: NO Removing 'safSi=AmfDemo1,safApp=AmfDemo1' from 'safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1' 2016-08-23 20:18:53 PL-4 osafamfnd[421]: NO Assigning 'safSi=AmfDemo1,safApp=AmfDemo1' STANDBY to 'safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1' 2016-08-23 20:18:53 PL-4 amf_demo[568]: CSI Set - add 'safCsi=AmfDemo,safSi=AmfDemo1,safApp=AmfDemo1' HAState Standby 2016-08-23 20:18:53 PL-4 osafamfnd[421]: NO Assigned 'safSi=AmfDemo1,safApp=AmfDemo1' STANDBY to 'safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1' ... 2016-08-23 20:19:24 PL-4 osafamfnd[421]: NO Sending node up due to NCSMDS_NEW_ACTIVE 2016-08-23 20:19:24 PL-4 osafamfnd[421]: NO 2 SISU states sent 2016-08-23 20:19:24 PL-4 osafamfnd[421]: NO 3 SU states sent 2016-08-23 20:19:24 PL-4 osafamfnd[421]: NO 6 CSICOMP states synced 2016-08-23 20:19:24 PL-4 osafamfnd[421]: NO 7 SU states sent 2016-08-23 20:19:24 PL-4 osafckptnd[441]: NO CLM selection object was updated. (11) 2016-08-23 20:19:24 PL-4 osafimmnd[397]: NO Implementer connected: 17 (safAmfService) <0, 2010f> 2016-08-23 20:19:25 PL-4 osafimmnd[397]: NO Implementer connected: 18 (safCheckPointService) <0, 2010f> 2016-08-23 20:19:25 PL-4 osafimmnd[397]: NO Implementer disconnected 18 <0, 2010f> (safCheckPointService) 2016-08-23 20:19:25 PL-4 osafimmnd[397]: NO Implementer connected: 19 (safCheckPointService) <0, 2010f> 2016-08-23 20:19:25 PL-4 osafimmnd[397]: NO Implementer connected: 20 (safSmfService) <0, 2010f> 2016-08-23 20:19:26 PL-4 osafamfnd[421]: NO Assigning 'safSi=AmfDemo1,safApp=AmfDemo1' ACTIVE to 'safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1' 2016-08-23 20:19:26 PL-4 amf_demo[568]: CSI Set - HAState Active for all assigned CSIs 2016-08-23 20:19:26 PL-4 osafamfnd[421]: NO Assigned 'safSi=AmfDemo1,safApp=AmfDemo1' ACTIVE to 'safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1' 2016-08-23 20:19:26 PL-4 osafamfnd[421]: NO Assigning 'safSi=AmfDemo1,safApp=AmfDemo1' STANDBY to 'safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1' 2016-08-23 20:19:26 PL-4 amf_demo[579]: CSI Set - add 'safCsi=AmfDemo,safSi=AmfDemo1,safApp=AmfDemo1' HAState Standby 2016-08-23 20:19:26 PL-4 osafamfnd[421]: NO Assigned 'safSi=AmfDemo1,safApp=AmfDemo1' STANDBY to 'safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1' Thanks, Minh On 23/08/16 19:48, Nagendra Kumar wrote: > Please note that it is on change set 7846:31417997c82f and I have applied > patch of ticket #1894. > > Thanks > -Nagu >> -Original Message- >> From: Nagendra Kumar >> Sent: 23 August 2016 15:15 >> To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; >> gary@dektech.com.au; long.hb.ngu...@dektech.com.au >> Cc: opensaf-devel@lists.sourceforge.net >> Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi >> callback completes during headless [#1725 part 1] V1 >> >> Hi Minh, >> The following SU lock case is not working. This issue will exist for all >> the flows, so please check. >> >> Configuration and traces attached in the ticket. >> >> Steps: >> 1. Start SC-1, SC-2, PL-3 and PL-4. Run the following command: >> immcfg -f /tmp/AppConfig-2N-1725.xml >> amf-adm unlock-in safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 >> amf-adm unlock-in safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 >> amf-adm unlock-in safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1 >> amf-adm unlock safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 >> amf-adm unlock safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 >> amf-adm unlock safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1 >> >> Assignments are: >> PM_SC-1:/home/nagu/views/staging-1725 # /etc/init.d/opensafd status >> safSISU=safSu=SC- >> 1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF >> saAmfSISUHAState=ACTIVE(1) >> safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC- >> 2N,safApp=OpenSAF >> saAmfSISUHAState=ACTIVE(1) >> safSISU=safSu=SC- >> 2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF >> saAmfSISUHAState=ACTIVE(1) >> safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC- >> 2N,safApp=OpenSAF >> saAmfSISUHAState=STANDBY(2) >> safSISU=safSu=PL- >> 4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF >> saAmfSISUHAState=ACTIVE(1) >> safSISU=safSu=PL- >> 3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF >> saAmfSISUHAState=ACTIVE(1) >> safS
Re: [devel] [PATCH 1 of 1] amfd: support NplusM model for supported admin ops on NG [#1454]
Hi Praveen,
I will use them for test.
Thanks,
Minh
On 23/08/16 16:58, praveen malviya wrote:
> Hi Minh,
>
> I have attached patches for #1454 and #1608 in the ticket #1454.
> Please apply them in order.
>
> Thanks,
> Praveen
>
> On 23-Aug-16 11:56 AM, minh chau wrote:
>> Hi Praveen,
>>
>> Since AMF longDn has been pushed, can you please attach a longDn rebased
>> version to ticket (both #1454 + #1608) so we can do some test?
>>
>> Thanks,
>> Minh
>>
>> On 23/08/16 15:56, praveen malviya wrote:
>>> Hi Minh,
>>>
>>> Thanks for reviewing the patch.
>>> Please see inline with [Praveen]
>>>
>>> Thanks,
>>> Praveen
>>>
>>>
>>>
>>> On 23-Aug-16 5:53 AM, minh chau wrote:
Hi Praveen,
One comment in line with [Minh]
Thanks
Minh
On 20/07/16 18:57, praveen.malv...@oracle.com wrote:
> osaf/services/saf/amf/amfd/include/sg.h | 1 +
> osaf/services/saf/amf/amfd/nodegroup.cc | 4 +-
> osaf/services/saf/amf/amfd/sg_npm_fsm.cc | 62
> ++-
> 3 files changed, 62 insertions(+), 5 deletions(-)
>
>
> Currently 2N, N-Way Active and NoRed models are supported for lock,
> shutdown,
> lock-in and unlock-in admin operations on NGs.
>
> This patch supports NplusM model also.
>
> diff --git a/osaf/services/saf/amf/amfd/include/sg.h
> b/osaf/services/saf/amf/amfd/include/sg.h
> --- a/osaf/services/saf/amf/amfd/include/sg.h
> +++ b/osaf/services/saf/amf/amfd/include/sg.h
> @@ -507,6 +507,7 @@ public:
> uint32_t susi_failed(AVD_CL_CB *cb, AVD_SU *su,
> struct avd_su_si_rel_tag *susi, AVSV_SUSI_ACT act,
> SaAmfHAStateT state);
> void node_fail_si_oper(AVD_CL_CB *cb, AVD_SU *su);
> +void ng_admin(AVD_SU *su, AVD_AMF_NG *ng);
> private:
> uint32_t su_fault_su_oper(AVD_CL_CB *cb, AVD_SU *su);
> 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
> @@ -687,6 +687,7 @@ void avd_ng_admin_state_set(AVD_AMF_NG*
> avd_send_admin_state_chg_ntf(&ng->name,
> (SaAmfNotificationMinorIdT)SA_AMF_NTFID_NG_ADMIN_STATE,
> old_state, ng->saAmfNGAdminState);
> +TRACE_LEAVE();
> }
> /**
>* @brief Verify if Node is stable for admin operation on
> Nodegroup
> etc.
> @@ -749,8 +750,7 @@ static SaAisErrorT check_red_model_servi
> LOG_NO("service outage for '%s' because of
> shutdown/lock "
> "on '%s'",sg->name.value,ng->name.value);
> -if ((sg->sg_redundancy_model ==
> SA_AMF_N_WAY_REDUNDANCY_MODEL) ||
> -(sg->sg_redundancy_model ==
> SA_AMF_NPM_REDUNDANCY_MODEL)) {
> +if (sg->sg_redundancy_model ==
> SA_AMF_N_WAY_REDUNDANCY_MODEL) {
> LOG_NO("Admin op on '%s' hosting SUs of '%s' with
> redundancy '%u' "
> "is not supported",ng->name.value,
> sg->name.value,
> sg->sg_redundancy_model);
> diff --git a/osaf/services/saf/amf/amfd/sg_npm_fsm.cc
> b/osaf/services/saf/amf/amfd/sg_npm_fsm.cc
> --- a/osaf/services/saf/amf/amfd/sg_npm_fsm.cc
> +++ b/osaf/services/saf/amf/amfd/sg_npm_fsm.cc
> @@ -120,16 +120,16 @@ static AVD_SU_SI_REL *avd_sg_npm_su_othr
> if (i_susi->si->list_of_sisu != i_susi) {
> o_susi = i_susi->si->list_of_sisu;
> if (o_susi->fsm != AVD_SU_SI_STATE_UNASGN)
> -return o_susi;
> +break;
> } else if (i_susi->si->list_of_sisu->si_next !=
> AVD_SU_SI_REL_NULL) {
> o_susi = i_susi->si->list_of_sisu->si_next;
> if (o_susi->fsm != AVD_SU_SI_STATE_UNASGN)
> -return o_susi;
> +break;
> }
> i_susi = i_susi->su_next;
> }
> -
> +TRACE_LEAVE2("o_susi:'%p'",o_susi);
> return o_susi;
> }
> @@ -4452,6 +4452,62 @@ uint32_t SG_NPM::sg_admin_down(AVD_CL_CB
> return NCSCC_RC_SUCCESS;
> }
> +/*
> + * @brief Handles modification of assignments in SU of NpM SG
> + * because of lock or shutdown operation on Node group.
> + * If SU does not have any SIs assigned to it, AMF will
> try
> + * to instantiate new SUs in the SG. If SU has
> assignments,
> + * then depending upon lock or shutdown operation,
> quiesced
> + * or quiescing state will be sent for active SIs in SU.
> + * If SU has only standby assignments then remove the
> assignments.
> + *
> + * @param[in] ptr to SU
> + * @param[in] ptr to nodegroup AVD_AMF_N
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
Hi Nagu, I see in the trace you provided, the SU2/SU3 become IN_SERVICE late. If there's a delay in PL4 joining cluster after headless in your test then you could also see it in the latest patches (longDN rebased version) I'm looking in to this issue. Thanks. Minh On 23/08/16 20:24, Nagendra Kumar wrote: > Please ignore TC #2, my mistake. > > Thanks > -Nagu > >> -Original Message- >> From: Nagendra Kumar >> Sent: 23 August 2016 15:49 >> To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; >> gary@dektech.com.au; long.hb.ngu...@dektech.com.au >> Cc: opensaf-devel@lists.sourceforge.net >> Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi >> callback completes during headless [#1725 part 1] V1 >> >> Please consider previous TC as TC #1 >> >> TC #2: Same configuration as TC #1. Logs attached in the ticket TC #2. >> >> Steps: >> 1. Same as step #1 of TC #1. >> 2. After locking SU1, keep delay in avnd_evt_avd_info_su_si_assign_evh and >> stop SC-1 and SC-2. >> 3. Start SC-1 and SC-2. SU1 is still in quisced state. Ideally, it should >> have no >> assignment and SU3 should have got assignment. >> >> safSISU=safSu=SU3\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe >> mo1,safApp=AmfDemo1 >> saAmfSISUHAState=STANDBY(2) >> safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe >> mo1,safApp=AmfDemo1 >> saAmfSISUHAState=ACTIVE(1) >> safSISU=safSu=PL- >> 4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF >> saAmfSISUHAState=ACTIVE(1) >> safSISU=safSu=SC- >> 1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF >> saAmfSISUHAState=ACTIVE(1) >> safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC- >> 2N,safApp=OpenSAF >> saAmfSISUHAState=ACTIVE(1) >> safSISU=safSu=SC- >> 2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF >> saAmfSISUHAState=ACTIVE(1) >> safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC- >> 2N,safApp=OpenSAF >> saAmfSISUHAState=STANDBY(2) >> safSISU=safSu=PL- >> 3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF >> saAmfSISUHAState=ACTIVE(1) >> >> After that PL-3 rebooted by the following logs: >> Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: TIMEOUT receiving AMF >> health check request, generating core for amfnd Aug 23 15:31:52 PM_PL-3 >> osafamfwd[18056]: Last received healthcheck cnt=82 at Tue Aug 23 15:30:52 >> 2016 Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: Rebooting OpenSAF >> NodeId = 0 EE Name = No EE Mapped, Reason: AMFND unresponsive, >> AMFWDOG initiated system reboot, OwnNodeId = 131855, SupervisionTime >> = 60 Aug 23 15:31:52 PM_PL-3 opensaf_reboot: Rebooting local node; >> timeout=60 >> >> Thanks >> -Nagu >> >>> -Original Message- >>> From: Nagendra Kumar >>> Sent: 23 August 2016 15:19 >>> To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; >>> gary@dektech.com.au; long.hb.ngu...@dektech.com.au >>> Cc: opensaf-devel@lists.sourceforge.net >>> Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi >>> callback completes during headless [#1725 part 1] V1 >>> >>> Please note that it is on change set 7846:31417997c82f and I have >>> applied patch of ticket #1894. >>> >>> Thanks >>> -Nagu -Original Message- From: Nagendra Kumar Sent: 23 August 2016 15:15 To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; gary@dektech.com.au; long.hb.ngu...@dektech.com.au Cc: opensaf-devel@lists.sourceforge.net Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1 Hi Minh, The following SU lock case is not working. This issue will exist for all the flows, so please check. Configuration and traces attached in the ticket. Steps: 1. Start SC-1, SC-2, PL-3 and PL-4. Run the following command: immcfg -f /tmp/AppConfig-2N-1725.xml amf-adm unlock-in safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 amf-adm unlock-in safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 amf-adm unlock-in safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1 amf-adm unlock safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 amf-adm unlock safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 amf-adm unlock safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1 Assignments are: PM_SC-1:/home/nagu/views/staging-1725 # /etc/init.d/opensafd status safSISU=safSu=SC- 1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC- 2N,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) safSISU=safSu=SC- 2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC- 2N,safApp=OpenSAF saAmfSISUHAState=STANDBY(2) safSISU=safSu=PL- 4
Re: [devel] [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]
Hi Mahesh,
Yes, this is my understanding too, if TIPC_DROPPABLE = true tipc may drop
messages silently, at receive sock buffer full condition, but do not return
any ancillary message.
If TIPC_DROPPABLE = false tipc may drop message but will send an ancillary
message to inform about TIPC_ERR_OVERLOAD.
Correcting this and adding an abort is not backward compatible as some service
already handle flow control in some way, only log when packages are dropped.
Regarding ticket #1960 there are other solutions than introducing flow control
in MDS, e.g. expose an option to the service to choose connection oriented
or connection less.
The problem with dropped messages seems in one case related to, (by MDS),
intensive MDS logging.
/Thanks HansN
-Original Message-
From: A V Mahesh [mailto:mahesh.va...@oracle.com]
Sent: den 23 augusti 2016 11:27
To: Hans Nordebäck ; Anders Widell
; mathi.naic...@oracle.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]
Hi HansN,
It seems I am missing some thing , please allow me to under stand
If I currently understand you observation :
With current Opensaf code ( this #1957 patch NOT applied ) , by default
TIPC_DROPPABLE=true ,while running Opensaf with that binary when
TIPC_ERR_OVERLOAD occurring, TIPC is not given errors TIPC_ERRINFO or
TIPC_RETDATA and following code is not being get hit of function
recvfrom_connectionless(), is my understanding right ?
=
*if (anc->cmsg_type == TIPC_ERRINFO) {*
/* TIPC_ERRINFO - TIPC error code associated with a returned data message
or a connection termination message so abort */
m_MDS_LOG_CRITICAL("MDTM: undelivered message condition ancillary
data: TIPC_ERRINFO abort err :%s", strerror(errno) );
*abort();*
*} else if (anc->cmsg_type == TIPC_RETDATA) {*
/* If we set TIPC_DEST_DROPPABLE off messge (configure TIPC to return
rejected messages to the sender )
we will hit this when we implement MDS retransmit lost messages abort
can be replaced with flow control logic*/
for (i = anc->cmsg_len - sizeof(*anc); i > 0; i--) {
m_MDS_LOG_DBG("MDTM: returned byte 0x%02x\n", *cptr);
cptr++;
}
/* TIPC_RETDATA -The contents of a returned data message so abort */
m_MDS_LOG_CRITICAL("MDTM: undelivered message condition ancillary
data: TIPC_RETDATA abort err :%s", strerror(errno) );
*abort();*
}
=
-AVM
On 8/23/2016 1:08 PM, Hans Nordebäck wrote:
> Hi Mahesh,
>
> Please see response below with [HansN] /Thanks HansN
>
> -Original Message-
> From: A V Mahesh [mailto:mahesh.va...@oracle.com]
> Sent: den 23 augusti 2016 08:25
> To: Hans Nordebäck ; Anders Widell
> ; mathi.naic...@oracle.com
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: Re: [PATCH 1 of 1] MDS: Log TIPC dropped messages [#1957]
>
> Hi HansN
>
> Please see response below with [AVM]
>
> -AVM
>
> On 8/23/2016 11:41 AM, Hans Nordebäck wrote:
>> Hi Mahesh,
>>
>> please see comments below.
>>
>> /Thanks HansN
>>
>>
>> On 08/23/2016 07:21 AM, A V Mahesh wrote:
>>> Hi HansN,
>>>
>>> Let us fist discuss the error handling and abort, then we can come
>>> back to interpretation of TIPC currently does permit OR does not
>>> permit an application to send a multicast message with the
>>> "destination droppable" setting disabled.
>>>
>>> Let us disable TIPC_DEST_DROPPABLE, so that TIPC will try to return
>>> an undelivered multicast message to its sender and we can determine
>>> issue is because of TIPC_ERR_OVERLOAD, this helps in debugging , so
>>> that application may increased SO_SNDBUF/SO_RCVBUF to reduce the
>>> problem.
>>>
>>> But still we need to abort(), the reason for that is current MDS
>>> implementations doesn't have flow control logic ( no retry because
>>> of error ) , so Application like AMF can go wrong and cluster will
>>> go into unstable/recoverble state.
>>>
>> [HansN] In the current implementation messages are dropped silently
>> and no abort is done.
> [AVM] I can see abort(); in current code , you mean abort(); is not working
> and application(amf) is not existing ?
> [HansN] In case of TIPC_DROPPABLE=true and messages are dropped,
> (TIPC_ERR_OVERLOAD) no abort is be performed, e.g amfd detects this in the
> msg sanity chk and logs "invalid msg id ..."
> ==
> ==
> if (anc->cmsg_type == TIPC_ERRINFO) {
> /* TIPC_ERRINFO - TIPC error code associated with a returned data
> message or a connection termination message so abort */
> m_MDS_LOG_CRITICAL("MDTM: undelivered message condition
> ancillary
> data: TIPC_ERRINFO abort err :%s", strerror(errno) );
> *abort();*
> } else if (anc->cmsg_type == TIPC_RE
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
Hi Minh, This issue is coming with latest patch also. I am facing this frequently on my setup and not able to proceed for testing. Please look into this on priority. Thanks -Nagu > -Original Message- > From: minh chau [mailto:minh.c...@dektech.com.au] > Sent: 23 August 2016 16:34 > To: Nagendra Kumar; hans.nordeb...@ericsson.com; Praveen Malviya; > gary@dektech.com.au; long.hb.ngu...@dektech.com.au > Cc: opensaf-devel@lists.sourceforge.net > Subject: Re: [PATCH 2 of 2] AMFND: Admin operation continuation if csi > callback completes during headless [#1725 part 1] V1 > > Hi Nagu, > > I see in the trace you provided, the SU2/SU3 become IN_SERVICE late. If > there's a delay in PL4 joining cluster after headless in your test then you > could also see it in the latest patches (longDN rebased version) I'm looking > in > to this issue. > > Thanks. > Minh > > On 23/08/16 20:24, Nagendra Kumar wrote: > > Please ignore TC #2, my mistake. > > > > Thanks > > -Nagu > > > >> -Original Message- > >> From: Nagendra Kumar > >> Sent: 23 August 2016 15:49 > >> To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; > >> gary@dektech.com.au; long.hb.ngu...@dektech.com.au > >> Cc: opensaf-devel@lists.sourceforge.net > >> Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if > >> csi callback completes during headless [#1725 part 1] V1 > >> > >> Please consider previous TC as TC #1 > >> > >> TC #2: Same configuration as TC #1. Logs attached in the ticket TC #2. > >> > >> Steps: > >> 1. Same as step #1 of TC #1. > >> 2. After locking SU1, keep delay in > >> avnd_evt_avd_info_su_si_assign_evh and stop SC-1 and SC-2. > >> 3. Start SC-1 and SC-2. SU1 is still in quisced state. Ideally, it > >> should have no assignment and SU3 should have got assignment. > >> > >> > safSISU=safSu=SU3\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe > >> mo1,safApp=AmfDemo1 > >> saAmfSISUHAState=STANDBY(2) > >> > safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe > >> mo1,safApp=AmfDemo1 > >> saAmfSISUHAState=ACTIVE(1) > >> safSISU=safSu=PL- > >> 4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF > >> saAmfSISUHAState=ACTIVE(1) > >> safSISU=safSu=SC- > >> 1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF > >> saAmfSISUHAState=ACTIVE(1) > >> safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC- > >> 2N,safApp=OpenSAF > >> saAmfSISUHAState=ACTIVE(1) > >> safSISU=safSu=SC- > >> 2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF > >> saAmfSISUHAState=ACTIVE(1) > >> safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC- > >> 2N,safApp=OpenSAF > >> saAmfSISUHAState=STANDBY(2) > >> safSISU=safSu=PL- > >> 3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF > >> saAmfSISUHAState=ACTIVE(1) > >> > >> After that PL-3 rebooted by the following logs: > >> Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: TIMEOUT receiving AMF > >> health check request, generating core for amfnd Aug 23 15:31:52 > >> PM_PL-3 > >> osafamfwd[18056]: Last received healthcheck cnt=82 at Tue Aug 23 > >> 15:30:52 > >> 2016 Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: Rebooting OpenSAF > >> NodeId = 0 EE Name = No EE Mapped, Reason: AMFND unresponsive, > >> AMFWDOG initiated system reboot, OwnNodeId = 131855, > SupervisionTime > >> = 60 Aug 23 15:31:52 PM_PL-3 opensaf_reboot: Rebooting local node; > >> timeout=60 > >> > >> Thanks > >> -Nagu > >> > >>> -Original Message- > >>> From: Nagendra Kumar > >>> Sent: 23 August 2016 15:19 > >>> To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; > >>> gary@dektech.com.au; long.hb.ngu...@dektech.com.au > >>> Cc: opensaf-devel@lists.sourceforge.net > >>> Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if > >>> csi callback completes during headless [#1725 part 1] V1 > >>> > >>> Please note that it is on change set 7846:31417997c82f and I have > >>> applied patch of ticket #1894. > >>> > >>> Thanks > >>> -Nagu > -Original Message- > From: Nagendra Kumar > Sent: 23 August 2016 15:15 > To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; > gary@dektech.com.au; long.hb.ngu...@dektech.com.au > Cc: opensaf-devel@lists.sourceforge.net > Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if > csi callback completes during headless [#1725 part 1] V1 > > Hi Minh, > The following SU lock case is not working. This issue will exist > for all the flows, so please check. > > Configuration and traces attached in the ticket. > > Steps: > 1. Start SC-1, SC-2, PL-3 and PL-4. Run the following command: > immcfg -f /tmp/AppConfig-2N-1725.xml amf-adm unlock-in > safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 > amf-adm unlock-in safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 > amf-adm unlock-in safSu=SU3,safSg=AmfDemo_2N,saf
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
In susi_success_su_oper() there is a check on Readiness state of SU, if it is inservice then only AMFD performs switchover. Why SUs of a node that is not synced is becoming IN_SERVICE. Also the AMFND where locked SU is hosted, should send buffered message only when its NCS SUs are assigned. Such a check can be included in avnd_diq_rec_send_buffered_msg(). Thanks, Praveen On 23-Aug-16 4:33 PM, minh chau wrote: > Hi Nagu, > > I see in the trace you provided, the SU2/SU3 become IN_SERVICE late. If > there's a delay in PL4 joining cluster after headless in your test then > you could also see it in the latest patches (longDN rebased version) > I'm looking in to this issue. > > Thanks. > Minh > > On 23/08/16 20:24, Nagendra Kumar wrote: >> Please ignore TC #2, my mistake. >> >> Thanks >> -Nagu >> >>> -Original Message- >>> From: Nagendra Kumar >>> Sent: 23 August 2016 15:49 >>> To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; >>> gary@dektech.com.au; long.hb.ngu...@dektech.com.au >>> Cc: opensaf-devel@lists.sourceforge.net >>> Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi >>> callback completes during headless [#1725 part 1] V1 >>> >>> Please consider previous TC as TC #1 >>> >>> TC #2: Same configuration as TC #1. Logs attached in the ticket TC #2. >>> >>> Steps: >>> 1. Same as step #1 of TC #1. >>> 2. After locking SU1, keep delay in >>> avnd_evt_avd_info_su_si_assign_evh and >>> stop SC-1 and SC-2. >>> 3. Start SC-1 and SC-2. SU1 is still in quisced state. Ideally, it >>> should have no >>> assignment and SU3 should have got assignment. >>> >>> safSISU=safSu=SU3\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe >>> mo1,safApp=AmfDemo1 >>> saAmfSISUHAState=STANDBY(2) >>> safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe >>> mo1,safApp=AmfDemo1 >>> saAmfSISUHAState=ACTIVE(1) >>> safSISU=safSu=PL- >>> 4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF >>> saAmfSISUHAState=ACTIVE(1) >>> safSISU=safSu=SC- >>> 1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF >>> saAmfSISUHAState=ACTIVE(1) >>> safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC- >>> 2N,safApp=OpenSAF >>> saAmfSISUHAState=ACTIVE(1) >>> safSISU=safSu=SC- >>> 2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF >>> saAmfSISUHAState=ACTIVE(1) >>> safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC- >>> 2N,safApp=OpenSAF >>> saAmfSISUHAState=STANDBY(2) >>> safSISU=safSu=PL- >>> 3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF >>> saAmfSISUHAState=ACTIVE(1) >>> >>> After that PL-3 rebooted by the following logs: >>> Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: TIMEOUT receiving AMF >>> health check request, generating core for amfnd Aug 23 15:31:52 PM_PL-3 >>> osafamfwd[18056]: Last received healthcheck cnt=82 at Tue Aug 23 >>> 15:30:52 >>> 2016 Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: Rebooting OpenSAF >>> NodeId = 0 EE Name = No EE Mapped, Reason: AMFND unresponsive, >>> AMFWDOG initiated system reboot, OwnNodeId = 131855, SupervisionTime >>> = 60 Aug 23 15:31:52 PM_PL-3 opensaf_reboot: Rebooting local node; >>> timeout=60 >>> >>> Thanks >>> -Nagu >>> -Original Message- From: Nagendra Kumar Sent: 23 August 2016 15:19 To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; gary@dektech.com.au; long.hb.ngu...@dektech.com.au Cc: opensaf-devel@lists.sourceforge.net Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1 Please note that it is on change set 7846:31417997c82f and I have applied patch of ticket #1894. Thanks -Nagu > -Original Message- > From: Nagendra Kumar > Sent: 23 August 2016 15:15 > To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; > gary@dektech.com.au; long.hb.ngu...@dektech.com.au > Cc: opensaf-devel@lists.sourceforge.net > Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if > csi callback completes during headless [#1725 part 1] V1 > > Hi Minh, > The following SU lock case is not working. This issue will exist > for all the flows, so please check. > > Configuration and traces attached in the ticket. > > Steps: > 1. Start SC-1, SC-2, PL-3 and PL-4. Run the following command: > immcfg -f /tmp/AppConfig-2N-1725.xml amf-adm unlock-in > safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 > amf-adm unlock-in safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 > amf-adm unlock-in safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1 > amf-adm unlock safSu=SU1,safSg=AmfDemo_2N,safApp=AmfDemo1 > amf-adm unlock safSu=SU2,safSg=AmfDemo_2N,safApp=AmfDemo1 > amf-adm unlock safSu=SU3,safSg=AmfDemo_2N,safApp=AmfDemo1 > > Assignments are: > PM_SC-1:/home/nagu/views/staging-1725 # /etc/init.d/
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
On 23-Aug-16 5:41 PM, praveen malviya wrote: > > In susi_success_su_oper() there is a check on Readiness state of SU, if > it is inservice then only AMFD performs switchover. Why SUs of a node > that is not synced is becoming IN_SERVICE. > > Also the AMFND where locked SU is hosted, should send buffered message > only when its NCS SUs are assigned. Such a check can be included in > avnd_diq_rec_send_buffered_msg(). > I think I missed headless state here, NCS sus are already assigned. What we need is AMFND should send buffered assignments after cluster timer expiry and node sync timer expiry. In headless case, after node sync timer only valid node will be present in the system. So failover/switchover to them will not be an issue. At the same time cluter timer expiry needs to be honored because AMFD code for application assignment state works in APP state that is linked to cluster timer expiry. -Could we hold any assignment message received before cluster timer expiry and node sync timer expiry and process them after expiry? -Another way can be AMFND should send buffered assignments only after expiry of these timers. What if AMFND starts some timer (larger value among cluster timer and node sync timer) on receiving AMFD up and on expiry of this timer sends the buffered assignment message. Thanks, Praveen > Thanks, > Praveen > > On 23-Aug-16 4:33 PM, minh chau wrote: >> Hi Nagu, >> >> I see in the trace you provided, the SU2/SU3 become IN_SERVICE late. If >> there's a delay in PL4 joining cluster after headless in your test then >> you could also see it in the latest patches (longDN rebased version) >> I'm looking in to this issue. >> >> Thanks. >> Minh >> >> On 23/08/16 20:24, Nagendra Kumar wrote: >>> Please ignore TC #2, my mistake. >>> >>> Thanks >>> -Nagu >>> -Original Message- From: Nagendra Kumar Sent: 23 August 2016 15:49 To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; gary@dektech.com.au; long.hb.ngu...@dektech.com.au Cc: opensaf-devel@lists.sourceforge.net Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1 Please consider previous TC as TC #1 TC #2: Same configuration as TC #1. Logs attached in the ticket TC #2. Steps: 1. Same as step #1 of TC #1. 2. After locking SU1, keep delay in avnd_evt_avd_info_su_si_assign_evh and stop SC-1 and SC-2. 3. Start SC-1 and SC-2. SU1 is still in quisced state. Ideally, it should have no assignment and SU3 should have got assignment. safSISU=safSu=SU3\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe mo1,safApp=AmfDemo1 saAmfSISUHAState=STANDBY(2) safSISU=safSu=SU2\,safSg=AmfDemo_2N\,safApp=AmfDemo1,safSi=AmfDe mo1,safApp=AmfDemo1 saAmfSISUHAState=ACTIVE(1) safSISU=safSu=PL- 4\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed4,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) safSISU=safSu=SC- 1\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed1,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) safSISU=safSu=SC-1\,safSg=2N\,safApp=OpenSAF,safSi=SC- 2N,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) safSISU=safSu=SC- 2\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed3,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) safSISU=safSu=SC-2\,safSg=2N\,safApp=OpenSAF,safSi=SC- 2N,safApp=OpenSAF saAmfSISUHAState=STANDBY(2) safSISU=safSu=PL- 3\,safSg=NoRed\,safApp=OpenSAF,safSi=NoRed2,safApp=OpenSAF saAmfSISUHAState=ACTIVE(1) After that PL-3 rebooted by the following logs: Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: TIMEOUT receiving AMF health check request, generating core for amfnd Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: Last received healthcheck cnt=82 at Tue Aug 23 15:30:52 2016 Aug 23 15:31:52 PM_PL-3 osafamfwd[18056]: Rebooting OpenSAF NodeId = 0 EE Name = No EE Mapped, Reason: AMFND unresponsive, AMFWDOG initiated system reboot, OwnNodeId = 131855, SupervisionTime = 60 Aug 23 15:31:52 PM_PL-3 opensaf_reboot: Rebooting local node; timeout=60 Thanks -Nagu > -Original Message- > From: Nagendra Kumar > Sent: 23 August 2016 15:19 > To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya; > gary@dektech.com.au; long.hb.ngu...@dektech.com.au > Cc: opensaf-devel@lists.sourceforge.net > Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi > callback completes during headless [#1725 part 1] V1 > > Please note that it is on change set 7846:31417997c82f and I have > applied patch of ticket #1894. > > Thanks > -Nagu >> -Original Message- >> From: Nagendra Kumar >> Sent: 23 August 2016 15:15 >> To: Minh Hon Chau; hans.nordeb...@ericsso
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
Thanks Praveen, I have the same thought as yours, the buffered
su_si_assignment should be sent when AMFD is in APP_STATE, it's the
state AMFD handling non-ncs SU.
I'm reusing set_leds msg, which signal veteran node to resend
su_si_assignment msg, patch is attached
Another thing could be improved in this situation, which is
su_si_assignment also has to be buffered while veteran is waiting for
set_leds, if susi assignment is done just in time after MDSNCS_UP/NEW_ACTIVE
I'll update this part later
@Nagu: I just did some tests, it seems to work, please apply this patch
on top the latest of part 1, sorry for this interruption :)
Thanks all
Minh
Here is the diff
diff --git a/osaf/services/saf/amf/amfd/cluster.cc
b/osaf/services/saf/amf/amfd/cluster.cc
--- a/osaf/services/saf/amf/amfd/cluster.cc
+++ b/osaf/services/saf/amf/amfd/cluster.cc
@@ -54,6 +54,7 @@ void avd_cluster_tmr_init_evh(AVD_CL_CB
{
TRACE_ENTER();
AVD_SU *su = nullptr;
+AVD_AVND *node = nullptr;
saflog(LOG_NOTICE, amfSvcUsrName, "Cluster startup timeout,
assigning SIs to SUs");
osafassert(evt->info.tmr.type == AVD_TMR_CL_INIT);
@@ -72,6 +73,15 @@ void avd_cluster_tmr_init_evh(AVD_CL_CB
cb->init_state = AVD_APP_STATE;
m_AVSV_SEND_CKPT_UPDT_ASYNC_UPDT(cb, cb, AVSV_CKPT_AVD_CB_CONFIG);
+// Resend set_leds to veteran node
+
+for (std::map::const_iterator it =
node_name_db->begin();
+it != node_name_db->end(); it++) {
+node = it->second;
+if (node->veteran)
+avd_snd_set_leds_msg(cb, node);
+}
+
/* call the realignment routine for each of the SGs in the
* system that are not NCS specific.
*/
diff --git a/osaf/services/saf/amf/amfd/include/node.h
b/osaf/services/saf/amf/amfd/include/node.h
--- a/osaf/services/saf/amf/amfd/include/node.h
+++ b/osaf/services/saf/amf/amfd/include/node.h
@@ -142,6 +142,7 @@ class AVD_AVND {
AVD_AMF_NG *admin_ng; /* points to the nodegroup on which admin
operation is going on.*/
uint16_t node_up_msg_count; /* to count of node_up msg that director
had received from this node */
bool reboot;
+ bool veteran;
//Member functions.
void node_sus_termstate_set(bool term_state) const;
diff --git a/osaf/services/saf/amf/amfd/ndfsm.cc
b/osaf/services/saf/amf/amfd/ndfsm.cc
--- a/osaf/services/saf/amf/amfd/ndfsm.cc
+++ b/osaf/services/saf/amf/amfd/ndfsm.cc
@@ -415,7 +415,7 @@ void avd_node_up_evh(AVD_CL_CB *cb, AVD_
// this node is already up
avd_node_state_set(avnd, AVD_AVND_STATE_PRESENT);
avd_node_oper_state_set(avnd, SA_AMF_OPERATIONAL_ENABLED);
-
+avnd->veteran = true;
// Update readiness state of all SUs which are waiting for
node
// oper state
for (const auto& su : avnd->list_of_ncs_su) {
@@ -677,6 +677,7 @@ void avd_mds_avnd_down_evh(AVD_CL_CB *cb
node->recvr_fail_sw = false;
node->node_info.initialViewNumber = 0;
node->node_info.member = SA_FALSE;
+node->veteran = false;
}
}
diff --git a/osaf/services/saf/amf/amfd/node.cc
b/osaf/services/saf/amf/amfd/node.cc
--- a/osaf/services/saf/amf/amfd/node.cc
+++ b/osaf/services/saf/amf/amfd/node.cc
@@ -153,6 +153,7 @@ AVD_AVND *avd_node_new(const std::string
node = new AVD_AVND(dn);
node->node_up_msg_count = 0;
node->reboot = false;
+node->veteran = false;
return node;
}
diff --git a/osaf/services/saf/amf/amfnd/di.cc
b/osaf/services/saf/amf/amfnd/di.cc
--- a/osaf/services/saf/amf/amfnd/di.cc
+++ b/osaf/services/saf/amf/amfnd/di.cc
@@ -1270,7 +1270,6 @@ void avnd_diq_rec_del(AVND_CB *cb, AVND_
/* stop the AvD msg response timer */
if (m_AVND_TMR_IS_ACTIVE(rec->resp_tmr)) {
m_AVND_TMR_MSG_RESP_STOP(cb, *rec);
-avnd_diq_rec_send_buffered_msg(cb);
/* resend pg start track */
avnd_di_resend_pg_start_track(cb);
}
diff --git a/osaf/services/saf/amf/amfnd/term.cc
b/osaf/services/saf/amf/amfnd/term.cc
--- a/osaf/services/saf/amf/amfnd/term.cc
+++ b/osaf/services/saf/amf/amfnd/term.cc
@@ -217,12 +217,14 @@ uint32_t avnd_evt_avd_set_leds_evh(AVND_
cb->rcv_msg_id = info->msg_id;
if (cb->led_state == AVND_LED_STATE_GREEN) {
-/* Nothing to be done we have already got this msg */
+// Resend buffered headless msg if NoRed MW SU is assigned ACTIVE
+avnd_diq_rec_send_buffered_msg(cb);
goto done;
}
cb->led_state = AVND_LED_STATE_GREEN;
+
/* Notify the NIS script/deamon that we have fully come up */
rc = nid_notify(const_cast("AMFND"), NCSCC_RC_SUCCESS,
nullptr);
On 23/08/16 23:01, praveen malviya wrote:
On 23-Aug-16 5:41 PM, praveen malviya wrote:
In susi_success_su_oper() there is a check on Readiness state of SU, if
it is inservice then only AMFD performs switchover. Why SUs of a node
that is not synced is becoming IN_SERVICE.
Also the AMFND where lo
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
Hi Praveen,
Please let me copy your questions and answer here in email, so it's
easier we can add comment in line, please see [Minh].
Thanks,
Minh
-
Hi Minh,
I am going through the patches 1725_phase1.tgz. Some initial comments:
1) In patch 2 avnd_diq_rec_send_buffered_msg() checks presence of SUSI
then only it sends buffered message to AMFD. In case removal of
assignments completes during headless , AMFND deletes the SUSIs in
su_si_oper_done(). So AMFND will never send the assignment message and
admin operation will not continue.
[Minh]: If this is the case AMFND deletes all SUSIs during headless,
then there will not be any assignment to be sent in state_info message
to AMFD after headless. However, in all admin operations of 2N I have
been testing,
the removal assignment sequence is the last step of admin LOCK/SHUTDOWN.
If AMFND deletes SUSI while headless, that also means the prior steps of
admin sequence had been done before headless. In this case, that is
equivalent to a completion of admin operation.
2) In patch1, I think after headless we will not get any invocation id
for the admin operation that
was going on before headless. Since AMF is continuing the admin
operation we should somehow
restrict other admin operation to start by setting some magic no for
invocationid or any other way.
[Minh]: If AMF is continuing the admin operation after headless, the sg
fsm state should not be STABLE, I think (sg_fsm_state ==
AVD_SG_FSM_STABLE) should be enough to reject new admin operation?
3)If suswitch is in TOGGLED state then I think we should crosscheck that
there are atleast two SUs
having assignment. The reason is if this flag remains TOGGOLED and admin
op does not continue then there is very less probability that if will
get reset as it is used only in si-swap flow.
[Minh]: Yes I don't particularly like this osafAmfSUSwitch to be written
to IMM. I had the only test case 144 failed (test list attached to ticket)
Test 144 is: Swap SI, delay csi STANDBY cbk in SU4, stop SCs, restart
SCs, reboot PL5. And I ran into the code line which requires suswitch
void SG_2N::node_fail_su_oper(AVD_SU *su) {
/* the SU has standby SI assignments. if the other SUs
switch field
* is true, it is in service, having quiesced assigning state.
* Send D2N-INFO_SU_SI_ASSIGN modify active all to the
other SU.
* Change switch field to false. Change state to SG_realign.
* Free all the SI assignments to this SU.
*/
if ((su_oper_list_front()->su_switch == AVSV_SI_TOGGLE_SWITCH)
&& (su_oper_list_front()->saAmfSuReadinessState ==
SA_AMF_READINESS_IN_SERVICE)) {
I think the *crosscheck* is actually a deduction of @su_switch from
whatever states that AMFD receives after headless. If *crosscheck* is
possible thing, then su_switch does not need to be checkpointed at
standby AMFD also.
In non-headless, we always need standby AMFD up-to-date all states by
checkpoint so that if active AMFD has gone, the standby AMFD can take
over by using these checkpointed states.
Now in headless, we also have to write these states somewhere (here is
IMM) so that the new active AMFD can use it.
It's the best that su_switch is revertible from a set of states, but
it's not easy to prove it's revertible from all scenarios of 2N si-swap.
If you think removing osafAmfSUSwitch is really needed, then this needs
to be looked more thoroughly later I think?
4)Since assignments are in progress. This could be because of admin
operation or
faults. AMFD should call one function here like log_admin_op(). This
function will search the entity
that is being under admin operation and log details like:
-After headless state admin op on '%s' is continuing in syslog.
-Also traces for susi states which are not assigned.
[Minh]: Agree, some sort of logging like this is good idea, I think it's
best to introduce this logging in the patch : [PATCH 4 of 4] AMFD:
Validate headless cached RTA read from IMM [#1725]
And maybe I need more details of what you would like to log.
Thanks,
Praveen
-
On 23/08/16 21:03, minh chau wrote:
> Hi Nagu,
>
> I see in the trace you provided, the SU2/SU3 become IN_SERVICE late.
> If there's a delay in PL4 joining cluster after headless in your test
> then you could also see it in the latest patches (longDN rebased version)
> I'm looking in to this issue.
>
> Thanks.
> Minh
>
> On 23/08/16 20:24, Nagendra Kumar wrote:
>> Please ignore TC #2, my mistake.
>>
>> Thanks
>> -Nagu
>>
>>> -Original Message-
>>> From: Nagendra Kumar
>>> Sent: 23 August 2016 15:49
>>> To: Minh Hon Chau; hans.nordeb...@ericsson.com; Praveen Malviya;
>>> gary@dektech.com.au; long.hb.ngu...@dektech.com.au
>>> Cc: opensaf-devel@lists.sourceforge.net
>>> Subject: RE: [PATCH 2 of 2] AMFND: Admin operation continuation if csi
>>> callback completes during headles
Re: [devel] [PATCH 1 of 1] pyosaf: Add __str__ method into non extended SaNameT class [#1737]
Hi,
If no more comment, it will be pushed by tomorrow (2016/08/25)
Thanks,
Quyen
-Original Message-
From: Hans Nordebäck [mailto:hans.nordeb...@ericsson.com]
Sent: Wednesday, August 10, 2016 7:27 PM
To: Quyen Dao ; srikanth.revan...@oracle.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] [PATCH 1 of 1] pyosaf: Add __str__ method into non
extended SaNameT class [#1737]
ack, code review only/Thanks HansN
On 08/05/2016 05:53 AM, Quyen Dao wrote:
> Hi,
>
> Please help review!
>
> Thanks,
> Quyen
>
> -Original Message-
> From: Quyen Dao [mailto:quyen@dektech.com.au]
> Sent: Wednesday, May 25, 2016 11:45 AM
> To: hans.nordeb...@ericsson.com; srikanth.revan...@oracle.com
> Cc: opensaf-devel@lists.sourceforge.net
> Subject: [devel] [PATCH 1 of 1] pyosaf: Add __str__ method into non
> extended SaNameT class [#1737]
>
> python/pyosaf/saAis.py | 5 +
> python/pyosaf/saImm.py | 2 +-
> python/pyosaf/saNtf.py | 3 ++-
> 3 files changed, 8 insertions(+), 2 deletions(-)
>
>
> with this change, user can call str(sa_name_t_obj) to convert SaNameT
> to str without caring it's extended or non extended.
>
> unmarshalSaImmValue and unmarshalSaNtfValue functions are also changed
> to support both extended and non extended SaNameT
>
> diff --git a/python/pyosaf/saAis.py b/python/pyosaf/saAis.py
> --- a/python/pyosaf/saAis.py
> +++ b/python/pyosaf/saAis.py
> @@ -198,6 +198,11 @@ else:
> """
> super(SaNameT, self).__init__(len(name), name)
>
> + def __str__(self):
> + """Returns the content of SaNameT
> + """
> + return self.value
> +
>
> class SaVersionT(Structure):
> """Contain software versions of area implementation.
> diff --git a/python/pyosaf/saImm.py b/python/pyosaf/saImm.py
> --- a/python/pyosaf/saImm.py
> +++ b/python/pyosaf/saImm.py
> @@ -71,7 +71,7 @@ def unmarshalSaImmValue(void_ptr, value_
> val_ptr = SaImmValueTypeMap.get(value_type)
> if val_ptr and void_ptr:
> if val_ptr == SaNameT:
> - return cast(void_ptr, POINTER(val_ptr))[0].value
> + return str(cast(void_ptr, POINTER(val_ptr))[0])
> return cast(void_ptr, POINTER(val_ptr))[0]
> return None
>
> diff --git a/python/pyosaf/saNtf.py b/python/pyosaf/saNtf.py
> --- a/python/pyosaf/saNtf.py
> +++ b/python/pyosaf/saNtf.py
> @@ -202,9 +202,10 @@ def unmarshalSaNtfValue(void_ptr, value_
> val_ptr = SaNtfValueTypeMap.get(value_type)
> if val_ptr and void_ptr:
> if val_ptr == SaNameT:
> - return cast(void_ptr, POINTER(val_ptr))[0].value
> + return str(cast(void_ptr, POINTER(val_ptr))[0])
> return cast(void_ptr, POINTER(val_ptr))[0]
> return None
> +
> class _ptrVal(Structure):
> _fields_ = [('dataOffset', SaUint16T),
> ('dataSize', SaUint16T)]
>
> --
> --
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of
> MDM restrictions. Mobile Device Manager Plus allows you to control
> only the apps on BYO-devices by containerizing them, leaving personal data
untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> 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
[devel] [PATCH 1 of 1] amfd: adapt unit tests for long DN support [#1642]
osaf/services/saf/amf/amfd/tests/test_amfdb.cc| 2 +-
osaf/services/saf/amf/amfd/tests/test_ckpt_enc_dec.cc | 46 +++---
2 files changed, 19 insertions(+), 29 deletions(-)
diff --git a/osaf/services/saf/amf/amfd/tests/test_amfdb.cc
b/osaf/services/saf/amf/amfd/tests/test_amfdb.cc
--- a/osaf/services/saf/amf/amfd/tests/test_amfdb.cc
+++ b/osaf/services/saf/amf/amfd/tests/test_amfdb.cc
@@ -16,7 +16,7 @@
*/
#include "gtest/gtest.h"
-#include "db_template.h"
+#include "amf_db_template.h"
class TEST_APP {
};
diff --git a/osaf/services/saf/amf/amfd/tests/test_ckpt_enc_dec.cc
b/osaf/services/saf/amf/amfd/tests/test_ckpt_enc_dec.cc
--- a/osaf/services/saf/amf/amfd/tests/test_ckpt_enc_dec.cc
+++ b/osaf/services/saf/amf/amfd/tests/test_ckpt_enc_dec.cc
@@ -39,12 +39,6 @@ class CkptEncDecTest : public ::testing:
virtual void TearDown() {
}
- const SaNameT* asSaNameT(const std::string& name) {
-sa_name_t.length = name.size();
-memcpy((char*)sa_name_t.value, name.c_str(), sa_name_t.length);
-return &sa_name_t;
- }
-
bool isLittleEndian() const {
union {
int i;
@@ -58,7 +52,6 @@ class CkptEncDecTest : public ::testing:
}
}
- SaNameT sa_name_t {};
NCS_MBCSV_CB_DEC dec {};
NCS_MBCSV_CB_ENC enc {};
NCS_UBAID uba {};
@@ -67,7 +60,7 @@ class CkptEncDecTest : public ::testing:
TEST_F(CkptEncDecTest, testEncDecAvdApp) {
int rc = 0;
std::string app_name {"AppName"};
- AVD_APP app(asSaNameT(app_name));
+ AVD_APP app(app_name);
app.saAmfApplicationAdminState = SA_AMF_ADMIN_LOCKED;
app.saAmfApplicationCurrNumSGs = 0x44332211;
@@ -81,7 +74,7 @@ TEST_F(CkptEncDecTest, testEncDecAvdApp)
enc.i_peer_version = AVD_MBCSV_SUB_PART_VERSION_3;
encode_app(&enc.io_uba, &app);
-
+
// retrieve saAmfApplicationCurrNumSGs encoded from the USR buf
int32_t size = enc.io_uba.ttl;
char *tmpData = new char[size];
@@ -99,11 +92,10 @@ TEST_F(CkptEncDecTest, testEncDecAvdApp)
}
delete [] tmpData;
-
- memset(&app, '\0', sizeof(AVD_APP));
+
decode_app(&enc.io_uba, &app);
- ASSERT_EQ(Amf::to_string(&app.name), "AppName");
+ ASSERT_EQ(app.name, "AppName");
ASSERT_EQ(app.saAmfApplicationAdminState, SA_AMF_ADMIN_LOCKED);
ASSERT_EQ(app.saAmfApplicationCurrNumSGs, static_cast(0x44332211));
}
@@ -112,13 +104,13 @@ TEST_F(CkptEncDecTest, testEncDecAvdComp
int rc = 0;
std::string comp_name{"CompName"};
std::string comp_proxy_name{"CompProxyName"};
- AVD_COMP comp(asSaNameT(comp_name));
+ AVD_COMP comp(comp_name);
comp.saAmfCompOperState = static_cast(0x44332211);
comp.saAmfCompReadinessState = static_cast(0x55443322);
comp.saAmfCompPresenceState = static_cast(0x66554433);
comp.saAmfCompRestartCount = 0x77665544;
- comp.saAmfCompCurrProxyName = *(asSaNameT(comp_proxy_name));
+ comp.saAmfCompCurrProxyName = comp_proxy_name;
rc = ncs_enc_init_space(&enc.io_uba);
ASSERT_TRUE(rc == NCSCC_RC_SUCCESS);
@@ -130,7 +122,7 @@ TEST_F(CkptEncDecTest, testEncDecAvdComp
enc.i_peer_version = AVD_MBCSV_SUB_PART_VERSION_3;
encode_comp(&enc.io_uba, &comp);
-
+
// retrieve AVD_COMP encoded data from the USR buf
int32_t size = enc.io_uba.ttl;
char *tmpData = new char[size];
@@ -157,7 +149,6 @@ TEST_F(CkptEncDecTest, testEncDecAvdComp
delete [] tmpData;
- memset(&comp, '\0', sizeof (AVD_COMP));
decode_comp(&enc.io_uba, &comp);
ASSERT_EQ(Amf::to_string(&comp.comp_info.name), "CompName");
@@ -165,7 +156,7 @@ TEST_F(CkptEncDecTest, testEncDecAvdComp
ASSERT_EQ(comp.saAmfCompReadinessState,
static_cast(0x55443322));
ASSERT_EQ(comp.saAmfCompPresenceState,
static_cast(0x66554433));
ASSERT_EQ(comp.saAmfCompRestartCount, static_cast(0x77665544));
- ASSERT_EQ(Amf::to_string(&comp.saAmfCompCurrProxyName), "CompProxyName");
+ ASSERT_EQ(comp.saAmfCompCurrProxyName, "CompProxyName");
}
TEST_F(CkptEncDecTest, testEncDecAvdSiAss) {
@@ -182,15 +173,15 @@ TEST_F(CkptEncDecTest, testEncDecAvdSiAs
rc = ncs_enc_init_space(&enc.io_uba);
ASSERT_TRUE(rc == NCSCC_RC_SUCCESS);
- su.name = *(asSaNameT(su_name));
- si.name = *(asSaNameT(si_name));
+ su.name = su_name;
+ si.name = si_name;
susi.su = &su;
susi.si = &si;
susi.state = SA_AMF_HA_ACTIVE;
susi.fsm = AVD_SU_SI_STATE_ABSENT;
susi.csi_add_rem = SA_FALSE;
- susi.comp_name = *(asSaNameT(comp_name));
- susi.csi_name = *(asSaNameT(csi_name));
+ susi.comp_name = comp_name;
+ susi.csi_name = csi_name;
enc.io_msg_type = NCS_MBCSV_MSG_ASYNC_UPDATE;
enc.io_action = NCS_MBCSV_ACT_UPDATE;
@@ -281,10 +272,10 @@ TEST_F(CkptEncDecTest, testEncDecAvdSiTr
std::string max_name("max_name");
AVSV_SI_TRANS_CKPT_MSG msg;
- min_assigned_su.name = *(asSaNameT(min_name));
- max_assigned_su.name = *(asSaNameT(max_name));
- tobe_redistributed.name = *(asSaNameT(si_name));
- sg.name = *(asSaNameT(sg_name));
+ min_assigned_su.name = min_name;
+ max_assigned_su.name = max_name;
+ tobe_redistribut
[devel] [PATCH 0 of 1] Review Request for amfd: adapt unit tests for long DN support [#1642]
Summary: amfd: adapt unit tests for long DN support [#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 servicesn OpenSAF servicesn Core libraries n Samples n Tests y Other n Comments (indicate scope for each "y" above): - changeset a81e3da07cb74e623b7feefa5836896dd25a47d2 Author: Gary Lee Date: Wed, 24 Aug 2016 13:45:13 +1000 amfd: adapt unit tests for long DN support [#1642] Complete diffstat: -- osaf/services/saf/amf/amfd/tests/test_amfdb.cc| 2 +- osaf/services/saf/amf/amfd/tests/test_ckpt_enc_dec.cc | 46 ++ 2 files changed, 19 insertions(+), 29 deletions(-) Testing Commands: - make check Testing, Expected Results: -- Unit tests pass Conditions of Submission: - <> Arch Built StartedLinux distro --- mipsn n mips64 n n x86 n n x86_64 n n powerpc n n powerpc64 n n Reviewer Checklist: --- [Submitters: make sure that your review doesn't trigger any checkmarks!] Your checkin has not passed review because (see checked entries): ___ Your RR template is generally incomplete; it has too many blank entries that need proper data filled in. ___ You have failed to nominate the proper persons for review and push. ___ Your patches do not have proper short+long header ___ You have grammar/spelling in your header that is unacceptable. ___ You have exceeded a sensible line length in your headers/comments/text. ___ You have failed to put in a proper Trac Ticket # into your commits. ___ You have incorrectly put/left internal data in your comments/files (i.e. internal bug tracking tool IDs, product names etc) ___ You have not given any evidence of testing beyond basic build tests. Demonstrate some level of runtime or other sanity testing. ___ You have ^M present in some of your files. These have to be removed. ___ You have needlessly changed whitespace or added whitespace crimes like trailing spaces, or spaces before tabs. ___ You have mixed real technical changes with whitespace and other cosmetic code cleanup changes. These have to be separate commits. ___ You need to refactor your submission into logical chunks; there is too much content into a single commit. ___ You have extraneous garbage in your review (merge commits etc) ___ You have giant attachments which should never have been sent; Instead you should place your content in a public tree to be pulled. ___ You have too many commits attached to an e-mail; resend as threaded commits, or place in a public tree for a pull. ___ You have resent this content multiple times without a clear indication of what has changed between each re-send. ___ You have failed to adequately and individually address all of the comments and change requests that were proposed in the initial review. ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc) ___ Your computer have a badly configured date and time; confusing the the threaded patch review. ___ Your changes affect IPC mechanism, and you don't present any results for in-service upgradability test. ___ Your changes affect user manual and documentation, your patch series do not contain the patch that updates the Doxygen manual. -- ___ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
Re: [devel] [PATCH 1 of 1] amfd: adapt unit tests for long DN support [#1642]
Hi Gary,
Ack (Tested).
Best regards,
Long Nguyen.
On 8/24/2016 10:47 AM, Gary Lee wrote:
> osaf/services/saf/amf/amfd/tests/test_amfdb.cc| 2 +-
> osaf/services/saf/amf/amfd/tests/test_ckpt_enc_dec.cc | 46
> +++---
> 2 files changed, 19 insertions(+), 29 deletions(-)
>
>
> diff --git a/osaf/services/saf/amf/amfd/tests/test_amfdb.cc
> b/osaf/services/saf/amf/amfd/tests/test_amfdb.cc
> --- a/osaf/services/saf/amf/amfd/tests/test_amfdb.cc
> +++ b/osaf/services/saf/amf/amfd/tests/test_amfdb.cc
> @@ -16,7 +16,7 @@
>*/
>
> #include "gtest/gtest.h"
> -#include "db_template.h"
> +#include "amf_db_template.h"
>
> class TEST_APP {
> };
> diff --git a/osaf/services/saf/amf/amfd/tests/test_ckpt_enc_dec.cc
> b/osaf/services/saf/amf/amfd/tests/test_ckpt_enc_dec.cc
> --- a/osaf/services/saf/amf/amfd/tests/test_ckpt_enc_dec.cc
> +++ b/osaf/services/saf/amf/amfd/tests/test_ckpt_enc_dec.cc
> @@ -39,12 +39,6 @@ class CkptEncDecTest : public ::testing:
> virtual void TearDown() {
> }
>
> - const SaNameT* asSaNameT(const std::string& name) {
> -sa_name_t.length = name.size();
> -memcpy((char*)sa_name_t.value, name.c_str(), sa_name_t.length);
> -return &sa_name_t;
> - }
> -
> bool isLittleEndian() const {
> union {
> int i;
> @@ -58,7 +52,6 @@ class CkptEncDecTest : public ::testing:
> }
> }
>
> - SaNameT sa_name_t {};
> NCS_MBCSV_CB_DEC dec {};
> NCS_MBCSV_CB_ENC enc {};
> NCS_UBAID uba {};
> @@ -67,7 +60,7 @@ class CkptEncDecTest : public ::testing:
> TEST_F(CkptEncDecTest, testEncDecAvdApp) {
> int rc = 0;
> std::string app_name {"AppName"};
> - AVD_APP app(asSaNameT(app_name));
> + AVD_APP app(app_name);
> app.saAmfApplicationAdminState = SA_AMF_ADMIN_LOCKED;
> app.saAmfApplicationCurrNumSGs = 0x44332211;
>
> @@ -81,7 +74,7 @@ TEST_F(CkptEncDecTest, testEncDecAvdApp)
> enc.i_peer_version = AVD_MBCSV_SUB_PART_VERSION_3;
>
> encode_app(&enc.io_uba, &app);
> -
> +
> // retrieve saAmfApplicationCurrNumSGs encoded from the USR buf
> int32_t size = enc.io_uba.ttl;
> char *tmpData = new char[size];
> @@ -99,11 +92,10 @@ TEST_F(CkptEncDecTest, testEncDecAvdApp)
> }
>
> delete [] tmpData;
> -
> - memset(&app, '\0', sizeof(AVD_APP));
> +
> decode_app(&enc.io_uba, &app);
>
> - ASSERT_EQ(Amf::to_string(&app.name), "AppName");
> + ASSERT_EQ(app.name, "AppName");
> ASSERT_EQ(app.saAmfApplicationAdminState, SA_AMF_ADMIN_LOCKED);
> ASSERT_EQ(app.saAmfApplicationCurrNumSGs,
> static_cast(0x44332211));
> }
> @@ -112,13 +104,13 @@ TEST_F(CkptEncDecTest, testEncDecAvdComp
> int rc = 0;
> std::string comp_name{"CompName"};
> std::string comp_proxy_name{"CompProxyName"};
> - AVD_COMP comp(asSaNameT(comp_name));
> + AVD_COMP comp(comp_name);
>
> comp.saAmfCompOperState = static_cast(0x44332211);
> comp.saAmfCompReadinessState =
> static_cast(0x55443322);
> comp.saAmfCompPresenceState =
> static_cast(0x66554433);
> comp.saAmfCompRestartCount = 0x77665544;
> - comp.saAmfCompCurrProxyName = *(asSaNameT(comp_proxy_name));
> + comp.saAmfCompCurrProxyName = comp_proxy_name;
>
> rc = ncs_enc_init_space(&enc.io_uba);
> ASSERT_TRUE(rc == NCSCC_RC_SUCCESS);
> @@ -130,7 +122,7 @@ TEST_F(CkptEncDecTest, testEncDecAvdComp
> enc.i_peer_version = AVD_MBCSV_SUB_PART_VERSION_3;
>
> encode_comp(&enc.io_uba, &comp);
> -
> +
> // retrieve AVD_COMP encoded data from the USR buf
> int32_t size = enc.io_uba.ttl;
> char *tmpData = new char[size];
> @@ -157,7 +149,6 @@ TEST_F(CkptEncDecTest, testEncDecAvdComp
>
> delete [] tmpData;
>
> - memset(&comp, '\0', sizeof (AVD_COMP));
> decode_comp(&enc.io_uba, &comp);
>
> ASSERT_EQ(Amf::to_string(&comp.comp_info.name), "CompName");
> @@ -165,7 +156,7 @@ TEST_F(CkptEncDecTest, testEncDecAvdComp
> ASSERT_EQ(comp.saAmfCompReadinessState,
> static_cast(0x55443322));
> ASSERT_EQ(comp.saAmfCompPresenceState,
> static_cast(0x66554433));
> ASSERT_EQ(comp.saAmfCompRestartCount, static_cast(0x77665544));
> - ASSERT_EQ(Amf::to_string(&comp.saAmfCompCurrProxyName), "CompProxyName");
> + ASSERT_EQ(comp.saAmfCompCurrProxyName, "CompProxyName");
> }
>
> TEST_F(CkptEncDecTest, testEncDecAvdSiAss) {
> @@ -182,15 +173,15 @@ TEST_F(CkptEncDecTest, testEncDecAvdSiAs
> rc = ncs_enc_init_space(&enc.io_uba);
> ASSERT_TRUE(rc == NCSCC_RC_SUCCESS);
>
> - su.name = *(asSaNameT(su_name));
> - si.name = *(asSaNameT(si_name));
> + su.name = su_name;
> + si.name = si_name;
> susi.su = &su;
> susi.si = &si;
> susi.state = SA_AMF_HA_ACTIVE;
> susi.fsm = AVD_SU_SI_STATE_ABSENT;
> susi.csi_add_rem = SA_FALSE;
> - susi.comp_name = *(asSaNameT(comp_name));
> - susi.csi_name = *(asSaNameT(csi_name));
> + susi.comp_name = comp_name;
> + susi.csi_name = csi_name;
>
> enc.io_msg_type = NCS_MBCSV_MSG_ASYNC_UPDATE;
>
Re: [devel] [PATCH 1 of 1] dtm: Fix cppcheck warnings [#1963]
Hi Anders Widell, ACK Reviewed & tested IPv4 & IPv6 -AVM On 8/23/2016 3:34 PM, Anders Widell wrote: > osaf/services/infrastructure/dtms/dtm/dtm_inter_svc.c|5 +- > osaf/services/infrastructure/dtms/dtm/dtm_intra.c| 10 +- > osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c| 18 +- > osaf/services/infrastructure/dtms/dtm/dtm_main.c | 18 - > osaf/services/infrastructure/dtms/dtm/dtm_node.c | 96 -- > osaf/services/infrastructure/dtms/dtm/dtm_node_db.c | 94 - > osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c | 236 > +-- > osaf/services/infrastructure/dtms/dtm/dtm_read_config.c | 41 +- > osaf/services/infrastructure/dtms/include/dtm.h |3 - > osaf/services/infrastructure/dtms/include/dtm_cb.h |2 +- > osaf/services/infrastructure/dtms/include/dtm_node.h |2 - > 11 files changed, 49 insertions(+), 476 deletions(-) > > > The following warnings, reported by cppcheck version 1.75, have been fixed: > > [osaf/services/infrastructure/dtms/dtm/dtm_inter_svc.c:342]: (style) The > scope of the variable 'buffer' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_intra.c:95]: (style) The scope of > the variable 'servlen' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_intra.c:97]: (style) The scope of > the variable 'server_ux_name' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_intra.c:155]: (style) Obsolescent > function 'bzero' called. It is recommended to use 'memset' instead. > [osaf/services/infrastructure/dtms/dtm/dtm_intra.c:207]: (error) > Uninitialized variable: serveraddr > [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:139]: (style) The > scope of the variable 'del_ptr' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:243]: (style) The > scope of the variable 'tmp' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:1836]: (style) The > scope of the variable 'local_svc_node' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:710]: (style) Variable > 'node_id' is assigned a value that is never used. > [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:320]: (error) Memory > leak: svc_node > [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:512]: (error) Memory > leak: subscr_node > [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:516]: (error) Memory > leak: subscr_info > [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:1728]: (error) Memory > leak: svc_info > [osaf/services/infrastructure/dtms/dtm/dtm_intra_svc.c:1754]: (error) Memory > leak: local_svc_info > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:54]: (style) > Assignment of function parameter has no effect outside the function. > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:74]: (style) The > scope of the variable 'optlen' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:423]: (style) The > scope of the variable 'err' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:617]: (style) The > scope of the variable 'ip_addr_eth' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:720]: (style) The > scope of the variable 'mcast_addr_eth' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:812]: (style) The > scope of the variable 'mcast_addr_eth' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1428]: (style) The > scope of the variable 'numericAddress' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1429]: (style) The > scope of the variable 'addrBuffer' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:191]: (error) > Uninitialized variable: join_request > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:192]: (error) > Uninitialized variable: join_request > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:950]: (error) > Uninitialized variable: addr_list > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1014]: (error) > Uninitialized variable: maddr > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1015]: (error) > Uninitialized variable: maddr > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1144]: (error) > Uninitialized variable: maddr > [osaf/services/infrastructure/dtms/dtm/dtm_node_sockets.c:1145]: (error) > Uninitialized variable: maddr > [osaf/services/infrastructure/dtms/dtm/dtm_read_config.c:139]: (style) The > scope of the variable 'tmp' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_read_config.c:140]: (style) The > scope of the variable 'buf' can be reduced. > [osaf/services/infrastructure/dtms/dtm/dtm_read_config.c:271]: (warning) > fscanf() without field width limits can crash with huge input data. > [osaf/services/infrastructure/dtms/dtm/dtm_read_config.c:327]: (error) > Res
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
Hi Minh,
Please see responses with [Praveen].
Thanks,
Praveen
On 23-Aug-16 7:18 PM, minh chau wrote:
> Hi Praveen,
>
> Please let me copy your questions and answer here in email, so it's
> easier we can add comment in line, please see [Minh].
>
> Thanks,
> Minh
>
> -
>
> Hi Minh,
> I am going through the patches 1725_phase1.tgz. Some initial comments:
> 1) In patch 2 avnd_diq_rec_send_buffered_msg() checks presence of SUSI
> then only it sends buffered message to AMFD. In case removal of
> assignments completes during headless , AMFND deletes the SUSIs in
> su_si_oper_done(). So AMFND will never send the assignment message and
> admin operation will not continue.
>
> [Minh]: If this is the case AMFND deletes all SUSIs during headless,
> then there will not be any assignment to be sent in state_info message
> to AMFD after headless. However, in all admin operations of 2N I have
> been testing,
> the removal assignment sequence is the last step of admin LOCK/SHUTDOWN.
> If AMFND deletes SUSI while headless, that also means the prior steps of
> admin sequence had been done before headless. In this case, that is
> equivalent to a completion of admin operation.
>
[Praveen]Yes, in this case it is not needed because by this time standby
SU has become active.
But in some cases AMFD performs failover/switchover based on removal of
assignments status particularly when fault happens during admin op. As
of now I do not know how to reproduce this scenario without faults but
with faults it is possible. Since patch is not for admin op + faults ,so
it can be left for the future.
> 2) In patch1, I think after headless we will not get any invocation id
> for the admin operation that
> was going on before headless. Since AMF is continuing the admin
> operation we should somehow
> restrict other admin operation to start by setting some magic no for
> invocationid or any other way.
>
> [Minh]: If AMF is continuing the admin operation after headless, the sg
> fsm state should not be STABLE, I think (sg_fsm_state ==
> AVD_SG_FSM_STABLE) should be enough to reject new admin operation?
>
>
> 3)If suswitch is in TOGGLED state then I think we should crosscheck that
> there are atleast two SUs
> having assignment. The reason is if this flag remains TOGGOLED and admin
> op does not continue then there is very less probability that if will
> get reset as it is used only in si-swap flow.
>
> [Minh]: Yes I don't particularly like this osafAmfSUSwitch to be written
> to IMM. I had the only test case 144 failed (test list attached to ticket)
> Test 144 is: Swap SI, delay csi STANDBY cbk in SU4, stop SCs, restart
> SCs, reboot PL5. And I ran into the code line which requires suswitch
>
> void SG_2N::node_fail_su_oper(AVD_SU *su) {
>
>
> /* the SU has standby SI assignments. if the other SUs
> switch field
> * is true, it is in service, having quiesced assigning state.
> * Send D2N-INFO_SU_SI_ASSIGN modify active all to the other
> SU.
> * Change switch field to false. Change state to SG_realign.
> * Free all the SI assignments to this SU.
> */
> if ((su_oper_list_front()->su_switch == AVSV_SI_TOGGLE_SWITCH)
> && (su_oper_list_front()->saAmfSuReadinessState ==
> SA_AMF_READINESS_IN_SERVICE)) {
>
> I think the *crosscheck* is actually a deduction of @su_switch from
> whatever states that AMFD receives after headless. If *crosscheck* is
> possible thing, then su_switch does not need to be checkpointed at
> standby AMFD also.
> In non-headless, we always need standby AMFD up-to-date all states by
> checkpoint so that if active AMFD has gone, the standby AMFD can take
> over by using these checkpointed states.
> Now in headless, we also have to write these states somewhere (here is
> IMM) so that the new active AMFD can use it.
> It's the best that su_switch is revertible from a set of states, but
> it's not easy to prove it's revertible from all scenarios of 2N si-swap.
> If you think removing osafAmfSUSwitch is really needed, then this needs
> to be looked more thoroughly later I think?
>
> 4)Since assignments are in progress. This could be because of admin
> operation or
> faults. AMFD should call one function here like log_admin_op(). This
> function will search the entity
> that is being under admin operation and log details like:
> -After headless state admin op on '%s' is continuing in syslog.
> -Also traces for susi states which are not assigned.
>
> [Minh]: Agree, some sort of logging like this is good idea, I think it's
> best to introduce this logging in the patch : [PATCH 4 of 4] AMFD:
> Validate headless cached RTA read from IMM [#1725]
> And maybe I need more details of what you would like to log.
[Praveen] I think to start with only name of entity and its admin state
can be logged.
>
> Thanks,
> Praveen
>
> -
>
> On 23/08/16 21:03, minh chau wrote:
>> Hi Nagu,
>>
>>
Re: [devel] [PATCH 2 of 2] AMFND: Admin operation continuation if csi callback completes during headless [#1725 part 1] V1
Hi Praveen,
I have just attached to ticket the #1725 part 2 that supports fault of
node restart/poweroff while headless.
Can you help to review it? I will update the patch that adds the logging
as you suggested.
Thanks for reviewing,
Minh
On 24/08/16 16:07, praveen malviya wrote:
> Hi Minh,
>
> Please see responses with [Praveen].
>
>
> Thanks,
> Praveen
>
> On 23-Aug-16 7:18 PM, minh chau wrote:
>> Hi Praveen,
>>
>> Please let me copy your questions and answer here in email, so it's
>> easier we can add comment in line, please see [Minh].
>>
>> Thanks,
>> Minh
>>
>> -
>>
>> Hi Minh,
>> I am going through the patches 1725_phase1.tgz. Some initial comments:
>> 1) In patch 2 avnd_diq_rec_send_buffered_msg() checks presence of SUSI
>> then only it sends buffered message to AMFD. In case removal of
>> assignments completes during headless , AMFND deletes the SUSIs in
>> su_si_oper_done(). So AMFND will never send the assignment message and
>> admin operation will not continue.
>>
>> [Minh]: If this is the case AMFND deletes all SUSIs during headless,
>> then there will not be any assignment to be sent in state_info message
>> to AMFD after headless. However, in all admin operations of 2N I have
>> been testing,
>> the removal assignment sequence is the last step of admin LOCK/SHUTDOWN.
>> If AMFND deletes SUSI while headless, that also means the prior steps of
>> admin sequence had been done before headless. In this case, that is
>> equivalent to a completion of admin operation.
>>
> [Praveen]Yes, in this case it is not needed because by this time
> standby SU has become active.
> But in some cases AMFD performs failover/switchover based on removal
> of assignments status particularly when fault happens during admin op.
> As of now I do not know how to reproduce this scenario without faults
> but with faults it is possible. Since patch is not for admin op +
> faults ,so it can be left for the future.
>> 2) In patch1, I think after headless we will not get any invocation id
>> for the admin operation that
>> was going on before headless. Since AMF is continuing the admin
>> operation we should somehow
>> restrict other admin operation to start by setting some magic no for
>> invocationid or any other way.
>>
>> [Minh]: If AMF is continuing the admin operation after headless, the sg
>> fsm state should not be STABLE, I think (sg_fsm_state ==
>> AVD_SG_FSM_STABLE) should be enough to reject new admin operation?
>>
>>
>> 3)If suswitch is in TOGGLED state then I think we should crosscheck that
>> there are atleast two SUs
>> having assignment. The reason is if this flag remains TOGGOLED and admin
>> op does not continue then there is very less probability that if will
>> get reset as it is used only in si-swap flow.
>>
>> [Minh]: Yes I don't particularly like this osafAmfSUSwitch to be written
>> to IMM. I had the only test case 144 failed (test list attached to
>> ticket)
>> Test 144 is: Swap SI, delay csi STANDBY cbk in SU4, stop SCs, restart
>> SCs, reboot PL5. And I ran into the code line which requires suswitch
>>
>> void SG_2N::node_fail_su_oper(AVD_SU *su) {
>>
>>
>> /* the SU has standby SI assignments. if the other SUs
>> switch field
>> * is true, it is in service, having quiesced assigning
>> state.
>> * Send D2N-INFO_SU_SI_ASSIGN modify active all to the other
>> SU.
>> * Change switch field to false. Change state to SG_realign.
>> * Free all the SI assignments to this SU.
>> */
>> if ((su_oper_list_front()->su_switch ==
>> AVSV_SI_TOGGLE_SWITCH)
>> && (su_oper_list_front()->saAmfSuReadinessState ==
>> SA_AMF_READINESS_IN_SERVICE)) {
>>
>> I think the *crosscheck* is actually a deduction of @su_switch from
>> whatever states that AMFD receives after headless. If *crosscheck* is
>> possible thing, then su_switch does not need to be checkpointed at
>> standby AMFD also.
>> In non-headless, we always need standby AMFD up-to-date all states by
>> checkpoint so that if active AMFD has gone, the standby AMFD can take
>> over by using these checkpointed states.
>> Now in headless, we also have to write these states somewhere (here is
>> IMM) so that the new active AMFD can use it.
>> It's the best that su_switch is revertible from a set of states, but
>> it's not easy to prove it's revertible from all scenarios of 2N si-swap.
>> If you think removing osafAmfSUSwitch is really needed, then this needs
>> to be looked more thoroughly later I think?
>>
>> 4)Since assignments are in progress. This could be because of admin
>> operation or
>> faults. AMFD should call one function here like log_admin_op(). This
>> function will search the entity
>> that is being under admin operation and log details like:
>> -After headless state admin op on '%s' is continuing in syslog.
>> -Also traces for susi states which are not assigned.
>>
>> [Minh]: Agree, some sort of logging
