[devel] [PATCH 1 of 1] amfd: ignore invalid modification of saAmfSGMaxActiveSIsperSU/saAmfSGMaxStandbySIsperSU [#1361]
osaf/services/saf/amf/amfd/sg.cc | 31 +--
1 files changed, 25 insertions(+), 6 deletions(-)
saAmfSGMaxActiveSIsperSU is valid for NPM, N_WAY and N_WAY_ACTIVE and
invalid for Nored and 2N. So, modification of this attribute for
Nored and 2N redudancy models should be ignored.
saAmfSGMaxStandbySIsperSU is valid for NPM and N_WAY and
invalid for Nored, 2N and NwayAct. So, modification of this attribute for
Nored, 2N and NwayAct redudancy models should be ignored.
diff --git a/osaf/services/saf/amf/amfd/sg.cc b/osaf/services/saf/amf/amfd/sg.cc
--- a/osaf/services/saf/amf/amfd/sg.cc
+++ b/osaf/services/saf/amf/amfd/sg.cc
@@ -919,15 +919,34 @@ static void ccb_apply_modify_hdlr(CcbUti
} else if (!strcmp(attribute-attrName,
saAmfSGMaxActiveSIsperSU)) {
if (value_is_deleted)
sg-saAmfSGMaxActiveSIsperSU = -1;
- else
- sg-saAmfSGMaxActiveSIsperSU =
*((SaUint32T *)value);
- TRACE(Modified saAmfSGMaxActiveSIsperSU is
'%u', sg-saAmfSGMaxActiveSIsperSU);
+ else {
+ if ((sg-sg_redundancy_model ==
SA_AMF_NPM_REDUNDANCY_MODEL) ||
+
(sg-sg_redundancy_model == SA_AMF_N_WAY_REDUNDANCY_MODEL) ||
+
(sg-sg_redundancy_model == SA_AMF_N_WAY_ACTIVE_REDUNDANCY_MODEL)) {
+ sg-saAmfSGMaxActiveSIsperSU =
*((SaUint32T *)value);
+ TRACE(Modified
saAmfSGMaxActiveSIsperSU is '%u',
+
sg-saAmfSGMaxActiveSIsperSU);
+ } else {
+ LOG_NO('%s' attribute
saAmfSGMaxActiveSIsperSU not modified,
+not valid for
Nored/2N Redundancy models,
+ sg-name.value);
+ }
+ }
} else if (!strcmp(attribute-attrName,
saAmfSGMaxStandbySIsperSU)) {
if (value_is_deleted)
sg-saAmfSGMaxStandbySIsperSU = -1;
- else
- sg-saAmfSGMaxStandbySIsperSU =
*((SaUint32T *)value);
- TRACE(Modified saAmfSGMaxStandbySIsperSU is
'%u', sg-saAmfSGMaxStandbySIsperSU);
+ else {
+ if ((sg-sg_redundancy_model ==
SA_AMF_NPM_REDUNDANCY_MODEL) ||
+
(sg-sg_redundancy_model == SA_AMF_N_WAY_REDUNDANCY_MODEL)) {
+ sg-saAmfSGMaxStandbySIsperSU =
*((SaUint32T *)value);
+ TRACE(Modified
saAmfSGMaxStandbySIsperSU is '%u',
+
sg-saAmfSGMaxStandbySIsperSU);
+ } else {
+ LOG_NO('%s' attribute
saAmfSGMaxStandbySIsperSU not modified,
+not valid for
Nored/2N/NwayAct Redundancy models,
+ sg-name.value);
+ }
+ }
} else if (!strcmp(attribute-attrName,
saAmfSGAutoAdjustProb)) {
if (value_is_deleted)
sg-saAmfSGAutoAdjustProb =
sg_type-saAmfSgtDefAutoAdjustProb;
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
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 build: Use the C11 standard for C and the C++11 standard for C++ [#1374]
Summary: build: Use the C11 standard for C and the C++11 standard for C++ [#1374] Review request for Trac Ticket(s): 1374 Peer Reviewer(s): Mathi Pull request to: Affected branch(es): default(4.7) Development branch: default Impacted area Impact y/n Docsn Build systemy 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 628e30d32d1f9fa5c48021f62b6fa0d5ebd8f157 Author: Anders Widell anders.wid...@ericsson.com Date: Thu, 21 May 2015 13:28:44 +0200 build: Use the C11 standard for C and the C++11 standard for C++ [#1374] Use the C11 standard when compiling C code, and the C++11 standard when compiling C++ code. For GCC, this means that we also bump the recommended minimum version to 4.8.1, which is the first version where all major features of C++11 were fully implemented (though most C++11 features were implemented already in earlier versions). Complete diffstat: -- Makefile.common | 4 ++-- README | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) Testing Commands: - Build and start OpenSAF. Testing, Expected Results: -- OpenSAF should successfully build and start. Conditions of Submission: - Ack from Mathi 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. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
[devel] [PATCH 1 of 1] build: Use the C11 standard for C and the C++11 standard for C++ [#1374]
Makefile.common | 4 ++-- README | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) Use the C11 standard when compiling C code, and the C++11 standard when compiling C++ code. For GCC, this means that we also bump the recommended minimum version to 4.8.1, which is the first version where all major features of C++11 were fully implemented (though most C++11 features were implemented already in earlier versions). diff --git a/Makefile.common b/Makefile.common --- a/Makefile.common +++ b/Makefile.common @@ -12,8 +12,8 @@ AM_CPPFLAGS = \ $(CORE_INCLUDES) \ $(all_includes) -AM_CFLAGS = -Wall -fno-strict-aliasing -Werror -fPIC @OSAF_HARDEN_FLAGS@ -DINTERNAL_VERSION_ID='@INTERNAL_VERSION_ID@' -AM_CXXFLAGS = -Wall -fno-strict-aliasing -Werror -fPIC -D__STDC_FORMAT_MACROS @OSAF_HARDEN_FLAGS@ -DINTERNAL_VERSION_ID='@INTERNAL_VERSION_ID@' +AM_CFLAGS = -std=gnu11 -Wall -fno-strict-aliasing -Werror -fPIC @OSAF_HARDEN_FLAGS@ -DINTERNAL_VERSION_ID='@INTERNAL_VERSION_ID@' +AM_CXXFLAGS = -std=gnu++11 -Wall -fno-strict-aliasing -Werror -fPIC -D__STDC_FORMAT_MACROS @OSAF_HARDEN_FLAGS@ -DINTERNAL_VERSION_ID='@INTERNAL_VERSION_ID@' AM_LDFLAGS = -ldl -lrt -lpthread systemdversion = $(systemdmodversion) diff --git a/README b/README --- a/README +++ b/README @@ -258,7 +258,7 @@ The following software is required to bu * autoconf (2.61 or later) * libtool * pkg-config -* gcc/g++ (4.3 or later) +* gcc/g++ (4.8.1 or later) * GNU make * python-dev(el) * Optionally: -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
Re: [devel] [PATCH 0 of 1] Review Request for IMM: Correction to support for admin-op for aborting non critical ccbs [#1107]
Hi AndersBj, Reviewed and tested the patch. Ack. /Neel. On Thursday 21 May 2015 03:26 AM, Anders Bjornerstedt wrote: Summary: IMM: Correction to support for admin-op for aborting non critical ccbs [#1107] Review request for Trac Ticket(s): 1107 Peer Reviewer(s): Neel;Zoran Pull request to: Affected branch(es): default(4.7) Development branch: Impacted area Impact y/n Docsn Build systemn RPM/packaging n Configuration files n Startup scripts n SAF servicesy OpenSAF servicesn Core libraries n Samples n Tests n Other n Comments (indicate scope for each y above): - changeset a2d0bc92571db5d5aac892cb55e79aed1ad0bb32 Author: Anders Bjornerstedt anders.bjornerst...@ericsson.com Date: Wed, 20 May 2015 23:48:21 +0200 IMM: Correction to support for admin-op for aborting non critical ccbs [#1107] The original fix only worked for aborting CCBs where there was an OI actively involved in processing a ccb callback at the time of the admin-op. It did not work for the case where the CCB was currently idle, i.e. waiting for the next operation from the om-client and OIs waiting for the next callback corrsponding to the next om-request. Complete diffstat: -- osaf/services/saf/immsv/immnd/ImmModel.cc | 34 +++--- 1 files changed, 23 insertions(+), 11 deletions(-) Testing Commands: - Test to include idle ccbs can be done using immcfg in explicit commit mode. The error response will only be received by the om-client when it tries the next operation. For some reason that I do not yet understand the error string assigned does not get picked up by immcfg. Could simply be that this is not done by immcfg in explicit commit mode. Testing, Expected Results: -- Invoking the admin-op to abort non-critical ccbs will abort also ccbs that are idle, but not empty. Conditions of Submission: - Ack from Neel and Zoran. 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
[devel] [PATCH 1 of 2] amfd: validate CSType when creating CtCsType [#986, #1302]
osaf/services/saf/amf/amfd/ctcstype.cc| 24
osaf/services/saf/amf/amfd/imm.cc | 7 ++--
osaf/services/saf/amf/amfd/include/util.h | 1 +
osaf/services/saf/amf/amfd/util.cc| 45 +++
4 files changed, 74 insertions(+), 3 deletions(-)
Note: This patch 1 of 2 was floated by Hans F. against the ticket #986.
This patch will not be pushed as a part of #1302.
AMF allows to create a SaAmfCtCsType object although the SaAmfCSType object
referred to does not exist.
Fix by looking up the SaAmfCSType DN in the SaAmfCSType database.
This patch will protect the creation of invalid SaAmfCtCsType and
configuration will not be added into the system.
diff --git a/osaf/services/saf/amf/amfd/ctcstype.cc
b/osaf/services/saf/amf/amfd/ctcstype.cc
--- a/osaf/services/saf/amf/amfd/ctcstype.cc
+++ b/osaf/services/saf/amf/amfd/ctcstype.cc
@@ -20,8 +20,10 @@
#include immutil.h
#include logtrace.h
+#include include/util.h
#include comp.h
#include imm.h
+#include include/csi.h
AmfDbstd::string, AVD_CTCS_TYPE *ctcstype_db = NULL;
@@ -35,6 +37,28 @@ static int is_config_valid(const SaNameT
{
SaUint32T uint32;
char *parent;
+ SaNameT cstype_dn;
+
+ if (get_child_dn_from_ass_dn(dn, cstype_dn) != 0) {
+ report_ccb_validation_error(opdata, malformed DN '%s',
dn-value);
+ return 0;
+ }
+
+ if (cstype_db-find(Amf::to_string(cstype_dn)) == NULL) {
+ if (opdata == NULL) {
+ report_ccb_validation_error(opdata,
+ SaAmfCSType object '%s' does not exist in
model,
+ cstype_dn.value);
+ return 0;
+ }
+
+ if (ccbutil_getCcbOpDataByDN(opdata-ccbId, cstype_dn) ==
NULL) {
+ report_ccb_validation_error(opdata,
+ SaAmfCSType object '%s' does not exist in
model or CCB,
+ cstype_dn.value);
+ return 0;
+ }
+ }
/* Second comma should be parent */
if ((parent = strchr((char*)dn-value, ',')) == NULL) {
diff --git a/osaf/services/saf/amf/amfd/imm.cc
b/osaf/services/saf/amf/amfd/imm.cc
--- a/osaf/services/saf/amf/amfd/imm.cc
+++ b/osaf/services/saf/amf/amfd/imm.cc
@@ -1403,6 +1403,10 @@ unsigned int avd_imm_config_get(void)
** reported either. Off line tools can do this better.
*/
+ /* SaAmfCSType needed by validation of SaAmfCtCsType */
+ if (avd_cstype_config_get() != SA_AIS_OK)
+ goto done;
+
/* SaAmfCompType indirectly needed by SaAmfSUType */
if (avd_comptype_config_get() != SA_AIS_OK)
goto done;
@@ -1421,9 +1425,6 @@ unsigned int avd_imm_config_get(void)
if (avd_svctype_config_get() != SA_AIS_OK)
goto done;
- if (avd_cstype_config_get() != SA_AIS_OK)
- goto done;
-
if (avd_compglobalattrs_config_get() != SA_AIS_OK)
goto done;
diff --git a/osaf/services/saf/amf/amfd/include/util.h
b/osaf/services/saf/amf/amfd/include/util.h
--- a/osaf/services/saf/amf/amfd/include/util.h
+++ b/osaf/services/saf/amf/amfd/include/util.h
@@ -96,6 +96,7 @@ struct avd_comp_tag;
struct avd_comp_csi_rel_tag;
struct avd_csi_tag;
+int get_child_dn_from_ass_dn(const SaNameT *ass_dn, SaNameT *child_dn);
void avd_d2n_reboot_snd(struct avd_avnd_tag *node);
bool admin_op_is_valid(SaImmAdminOperationIdT opId, AVSV_AMF_CLASS_ID
class_id);
void amflog(int priority, const char *format, ...);
diff --git a/osaf/services/saf/amf/amfd/util.cc
b/osaf/services/saf/amf/amfd/util.cc
--- a/osaf/services/saf/amf/amfd/util.cc
+++ b/osaf/services/saf/amf/amfd/util.cc
@@ -1823,3 +1823,48 @@ bool admin_op_is_valid(SaImmAdminOperati
return valid;
}
+
+ /**
+ * Gets child DN from an association DN
+ * safDepend=safSi=SC2-NoRed\,safApp=OpenSAF,safSi=SC-2N,safApp=OpenSAF
+ * @param ass_dn association DN [in]
+ * @param child_dn [out]
+ * @return 0 at success
+ */
+ int get_child_dn_from_ass_dn(const SaNameT *ass_dn, SaNameT *child_dn)
+ {
+ SaNameT _ass_dn = *ass_dn;
+
+ /* find first comma and step past it */
+ char *p = strchr((char *)_ass_dn.value, ',');
+ if (p == NULL)
+ return -1;
+
+ p++;
+
+ /* find second comma, an error if not found */
+ p = strchr(p, ',');
+ if (p == NULL)
+ return -1;
+
+ *p = '\0'; /* null terminate at comma before parent */
+
+ /* Skip past the RDN tag */
+ p = strchr((char *)_ass_dn.value, '=');
+ if (p == NULL)
+ return -1;
+
+ p++;
+
+ /* copy and skip back slash */
+ int i = 0;
+ while (*p) {
+ if (*p != '\\')
+ child_dn-value[i++] = *p;
+ p++;
+ }
+
+
[devel] [PATCH 2 of 2] amfd: validate ctcstype relationship while modifying comptype in comp [#1302]
osaf/services/saf/amf/amfd/comp.cc| 32 +++
osaf/services/saf/amf/amfd/ctcstype.cc| 10 +
osaf/services/saf/amf/amfd/include/comp.h | 1 +
osaf/services/saf/amf/amfd/util.cc| 1 -
4 files changed, 43 insertions(+), 1 deletions(-)
Before modifying compType attribute in a comp, one more check on the validity of
SaAmfCtCsType is still required which means association (object of
SaAmfCtCsType)
between this new comptype and cstype in SaAmfCompCsType (in case such an object
exists for this component) must also exists in the system. If ctcstype does not
exist then there will be problem in deciding components capability for a given
cstype. So reject the modify ccb if ctstype does not exist with any cstypes
supported by this component via compcstype.
Thus assert can be removed as patch 1 and patch 2 will not allow any invalid
configuration in the syste.
diff --git a/osaf/services/saf/amf/amfd/comp.cc
b/osaf/services/saf/amf/amfd/comp.cc
--- a/osaf/services/saf/amf/amfd/comp.cc
+++ b/osaf/services/saf/amf/amfd/comp.cc
@@ -846,7 +846,39 @@ static SaAisErrorT ccb_completed_modify_
report_ccb_validation_error(opdata,
saAmfCompType '%s' not found, dn.value);
goto done;
}
+ /*
+ This new compType exists in the AMF. Before
modifying compType attribute in a comp,
+ one more check on the validity of SaAmfCtCsType is
still required which means
+ association object (object of SaAmfCtCsType) between
this new comptype and cstype
+ in SaAmfCompCsType (in case such an object exists
for this component) must also
+ exists in the system. If ctcstype does not exist
then there will be problem in
+ deciding components capability for a given cstype.
So reject the modify ccb if
+ ctcstype does not exist with any cstypes supported
by this component via compcstype.
+*/
+ for (std::mapstd::string,
AVD_COMPCS_TYPE*::const_iterator it = compcstype_db-begin();
+ it != compcstype_db-end(); it++) {
+ AVD_COMPCS_TYPE *compcstype = it-second;
+ if (compcstype-comp == comp) {
+ SaNameT cstype_name;
+ AVD_CTCS_TYPE *ctcstype = NULL;
+ avd_cstype_t *cst = NULL;
+
get_child_dn_from_ass_dn(compcstype-name, cstype_name);
+ //First check if this cstype exists in
the sustem.
+ if ((cst =
cstype_db-find(Amf::to_string(cstype_name))) == NULL) {
+ LOG_WA(cstype of '%s' is not
preseint in AMF database,
+
compcstype-name.value);
+ continue;
+ }
+ //ctcstype relationship should exists
with all the cstypes.
+ if ((ctcstype = get_ctcstype(dn,
cstype_name)) == NULL) {
+
report_ccb_validation_error(opdata, ctcstype relationship
+ between new
comptype and cstype from
+ component's
compcstype(s) does not exist);
+ goto done;
+ }
+ }
+ }
} else if (!strcmp(attribute-attrName,
saAmfCompInstantiateCmdArgv)) {
char *param_val = *((char **)value);
if (NULL == param_val) {
diff --git a/osaf/services/saf/amf/amfd/ctcstype.cc
b/osaf/services/saf/amf/amfd/ctcstype.cc
--- a/osaf/services/saf/amf/amfd/ctcstype.cc
+++ b/osaf/services/saf/amf/amfd/ctcstype.cc
@@ -217,6 +217,16 @@ static void ctcstype_ccb_apply_cb(CcbUti
TRACE_LEAVE();
}
+AVD_CTCS_TYPE *get_ctcstype(const SaNameT *comptype_name, const SaNameT
*cstype_name)
+{
+ SaNameT dn;
+ AVD_CTCS_TYPE *ctcs_type = NULL;
+ avsv_create_association_class_dn(cstype_name, comptype_name,
+ safSupportedCsType, dn);
+ ctcs_type = ctcstype_db-find(Amf::to_string(dn));
+ return ctcs_type;
+}
+
void avd_ctcstype_constructor(void)
{
ctcstype_db = new AmfDbstd::string, AVD_CTCS_TYPE;
diff --git a/osaf/services/saf/amf/amfd/include/comp.h
b/osaf/services/saf/amf/amfd/include/comp.h
---
[devel] [PATCH 0 of 2] Review Request for fix validation of CtCsType [#1302]
Summary: fix validation of CtCsType [#1302] Review request for Trac Ticket(s): #1302 Peer Reviewer(s): Hans N., Nagendra Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE Affected branch(es): ALL Development branch: IF ANY GIVE THE REPO URL 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): - Note: Patch series one patch (1 of 2) from #986. Patch is included for testing purpose and will not be pusdhed as part of #1302. changeset 3e62c8edc300a383f17f86c6eab2e6bc37d429ca Author: praveen.malv...@oracle.com Date: Thu, 21 May 2015 18:29:51 +0530 amfd: validate CSType when creating CtCsType [#986,#1302] Note: This patch 1 of 2 was floated by Hans F. against the ticket #986. This patch will not be pushed as a part of #1302. AMF allows to create a SaAmfCtCsType object although the SaAmfCSType object referred to does not exist. Fix by looking up the SaAmfCSType DN in the SaAmfCSType database. This patch will protect the creation of invalid SaAmfCtCsType and configuration will not be added into the system. changeset 4850674b73cd5267345d5676290a16aba214807f Author: praveen.malv...@oracle.com Date: Thu, 21 May 2015 18:30:22 +0530 amfd: validate ctcstype relationship while modifying comptype in comp [#1302] Before modifying compType attribute in a comp, one more check on the validity of SaAmfCtCsType is still required which means association (object of SaAmfCtCsType) between this new comptype and cstype in SaAmfCompCsType (in case such an object exists for this component) must also exists in the system. If ctcstype does not exist then there will be problem in deciding components capability for a given cstype. So reject the modify ccb if ctstype does not exist with any cstypes supported by this component via compcstype. Thus assert can be removed as patch 1 and patch 2 will not allow any invalid configuration in the syste. Complete diffstat: -- osaf/services/saf/amf/amfd/comp.cc| 32 osaf/services/saf/amf/amfd/ctcstype.cc| 34 ++ osaf/services/saf/amf/amfd/imm.cc | 7 --- osaf/services/saf/amf/amfd/include/comp.h | 1 + osaf/services/saf/amf/amfd/include/util.h | 1 + osaf/services/saf/amf/amfd/util.cc| 46 +- 6 files changed, 117 insertions(+), 4 deletions(-) Testing Commands: - Tested by trying to modify comptype in a component. Testing, Expected Results: -- CCB is rejected if ctcstype calidation passes Conditions of Submission: - Ack from any reviewer 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
[devel] [PATCH 0 of 1] Review Request for IMM: Detach of PBE aborts all non-critical and non-empty CCBs [#1261]
Summary: IMM: Detach of PBE aborts all non-critical and non-empty CCBs [#1261] Review request for Trac Ticket(s): 1261 Peer Reviewer(s): Neel; Zoran Pull request to: Affected branch(es): default(4.7) Development branch: default(4.7) 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 8073b1de0515c7a82cc4cdc89aee39a682a86e06 Author: Anders Bjornerstedt anders.bjornerst...@ericsson.com Date: Thu, 21 May 2015 14:26:58 +0200 IMM: Detach of PBE aborts all non-critical and non-empty CCBs [#1261] If the PBE detaches and re-attaches while there are one or more open non- critical (not yet committing) but non-empty CCBs, then before this enhancement one would see the following in the syslog at apply of the CCB: May 20 13:25:33 SC-2 local0.notice osafimmnd[406]: NO STARTING PBE process. .. May 20 13:25:34 SC-2 local0.notice osafimmnd[406]: NO PBE-OI established on this SC. Dumping incrementally to file imm.db May 20 13:25:49 SC-2 local0.info osafimmnd[406]: IN GOING FROM IMM_CCB_PREPARE to IMM_CCB_CRITICAL Ccb:4 May 20 13:25:49 SC-2 user.notice osafimmpbed: NO Record for ccb 0x4 not found or found aborted in ok_for_critical May 20 13:25:49 SC-2 user.warn osafimmpbed: WA WARNING: CCB record for 4 does not have correct op-count May 20 13:25:49 SC-2 local0.notice osafimmnd[406]: NO Invalid error reported implementer 'OpenSafImmPBE', Ccb 4 will be aborted While this does catch the problem and aborts the CCB, the op-count mechanism that catches this is not intended for handling regular processing cases. It is an extra safety harness intended to catch bugs, lost messages, or incorrect behavior of the PBE. This enhancement avoids dependence on the op-count safety harness by having the restarted PBE (primary or slave) invoking the special admin-operation that aborts all non-critical CCBs in the immsv. See enhancement ticket #1107 or the IMMSV README for details about his admin-operation. The newly (re)started PBE invokes the admin-operation asynchronously to avoid getting blocked waiting on reply for this admin-op. The risk of the admin-op failing is minimal and if it does fail then we end up in the same distributed logic as we have today. That is we would end up in the op-count safety-harness. No CCB can get applied without ack from the PBE and so the admin-operation, if it is successfully received by the IMMND coord, should result in all currently non-critical CCBS getting aborted before the PBE can get any completed/apply for such a CCB over FEVS. With this enhancement, if the PBE detaches and re-attaches while there are one or more open non-critical (not yet committing) and non-empty CCBs, then these CCBs will be aborted. The newly attached PBE may possibly get an abort callback for such CCbs, but these are ignored by the PBE. With this enhancement one will see something like the following in the syslog at an attempt tp apply a CCB that was active during detach and attach of PBE: May 21 12:41:34 SC-2 local0.notice osafimmnd[406]: NO Persistent Back End OI attached, pid: 764 May 21 12:41:34 SC-2 local0.notice osafimmnd[406]: NO Received: immadm -o 202 safRdn=immManagement,safApp=safImmService May 21 12:41:34 SC-2 local0.info osafimmnd[406]: IN sAbortNonCriticalCcbs = true; May 21 12:41:34 SC-2 local0.notice osafimmnd[406]: NO Implementer connected: 19 (OpenSafImmPBE) 332, 2020f May 21 12:41:34 SC-2 user.info osafimmpbed: IN Admop for aborting CCBs result: 1, immsv returned 1 May 21 12:41:34 SC-2 user.notice osafimmpbed: NO Update epoch 21 committing with ccbId:10014/4294967316 May 21 12:41:34 SC-2 local0.notice osafimmd[396]: NO IMMND coord at 2020f May 21 12:41:34 SC-2 local0.info osafimmnd[406]: IN Update of epoch is PERSISTENT. May 21 12:41:35 SC-2 local0.notice osafimmnd[406]: NO PBE-OI established on this SC. Dumping incrementally to file imm.db May 21 12:41:35 SC-2 local0.info osafimmnd[406]: IN sAbortNonCriticalCcbs is true = set max_oi_timeout to 0 May 21 12:41:35 SC-2 local0.notice osafimmnd[406]: NO CCB 5 aborted by: immadm -o 202 safRdn=immManagement,safApp=safImmService May 21 12:41:35 SC-2 local0.info
[devel] [PATCH 1 of 1] IMM: Detach of PBE aborts all non-critical and non-empty CCBs [#1261]
osaf/services/saf/immsv/immpbed/immpbe.cc | 24 ++--
1 files changed, 22 insertions(+), 2 deletions(-)
If the PBE detaches and re-attaches while there are one or more open
non-critical (not yet committing) but non-empty CCBs, then before this
enhancement one would see the following in the syslog at apply of the CCB:
May 20 13:25:33 SC-2 local0.notice osafimmnd[406]: NO STARTING PBE process.
..
May 20 13:25:34 SC-2 local0.notice osafimmnd[406]: NO PBE-OI established on
this SC. Dumping incrementally to file imm.db
May 20 13:25:49 SC-2 local0.info osafimmnd[406]: IN GOING FROM IMM_CCB_PREPARE
to IMM_CCB_CRITICAL Ccb:4
May 20 13:25:49 SC-2 user.notice osafimmpbed: NO Record for ccb 0x4 not found
or found aborted in ok_for_critical
May 20 13:25:49 SC-2 user.warn osafimmpbed: WA WARNING: CCB record for 4 does
not have correct op-count
May 20 13:25:49 SC-2 local0.notice osafimmnd[406]: NO Invalid error reported
implementer 'OpenSafImmPBE', Ccb 4 will be aborted
While this does catch the problem and aborts the CCB, the op-count mechanism
that catches this is not intended for handling regular processing cases.
It is an extra safety harness intended to catch bugs, lost messages, or
incorrect
behavior of the PBE.
This enhancement avoids dependence on the op-count safety harness by having the
restarted PBE (primary or slave) invoking the special admin-operation that
aborts
all non-critical CCBs in the immsv. See enhancement ticket #1107 or the IMMSV
README
for details about his admin-operation.
The newly (re)started PBE invokes the admin-operation asynchronously to avoid
getting
blocked waiting on reply for this admin-op. The risk of the admin-op failing is
minimal and if it does fail then we end up in the same distributed logic as we
have
today. That is we would end up in the op-count safety-harness. No CCB can get
applied
without ack from the PBE and so the admin-operation, if it is successfully
received by
the IMMND coord, should result in all currently non-critical CCBS getting
aborted before
the PBE can get any completed/apply for such a CCB over FEVS.
With this enhancement, if the PBE detaches and re-attaches while there are one
or more
open non-critical (not yet committing) and non-empty CCBs, then these CCBs will
be
aborted. The newly attached PBE may possibly get an abort callback for such
CCbs,
but these are ignored by the PBE.
With this enhancement one will see something like the following in the syslog
at an attempt
tp apply a CCB that was active during detach and attach of PBE:
May 21 12:41:34 SC-2 local0.notice osafimmnd[406]: NO Persistent Back End OI
attached, pid: 764
May 21 12:41:34 SC-2 local0.notice osafimmnd[406]: NO Received: immadm -o 202
safRdn=immManagement,safApp=safImmService
May 21 12:41:34 SC-2 local0.info osafimmnd[406]: IN sAbortNonCriticalCcbs =
true;
May 21 12:41:34 SC-2 local0.notice osafimmnd[406]: NO Implementer connected: 19
(OpenSafImmPBE) 332, 2020f
May 21 12:41:34 SC-2 user.info osafimmpbed: IN Admop for aborting CCBs result:
1, immsv returned 1
May 21 12:41:34 SC-2 user.notice osafimmpbed: NO Update epoch 21 committing
with ccbId:10014/4294967316
May 21 12:41:34 SC-2 local0.notice osafimmd[396]: NO IMMND coord at 2020f
May 21 12:41:34 SC-2 local0.info osafimmnd[406]: IN Update of epoch is
PERSISTENT.
May 21 12:41:35 SC-2 local0.notice osafimmnd[406]: NO PBE-OI established on
this SC. Dumping incrementally to file imm.db
May 21 12:41:35 SC-2 local0.info osafimmnd[406]: IN sAbortNonCriticalCcbs is
true = set max_oi_timeout to 0
May 21 12:41:35 SC-2 local0.notice osafimmnd[406]: NO CCB 5 aborted by: immadm
-o 202 safRdn=immManagement,safApp=safImmService
May 21 12:41:35 SC-2 local0.info osafimmnd[406]: IN sAbortNonCriticalCcbs reset
to false
May 21 12:41:35 SC-2 local0.warn osafimmnd[406]: WA Timeout while waiting for
implementer, aborting ccb:5
May 21 12:41:35 SC-2 user.warn osafimmpbed: WA Failed to find CCB object for 5/5
May 21 12:41:45 SC-2 local0.notice osafimmnd[406]: NO Ccb 5 not in correct
state (12) for Apply ignoring request
May 21 12:41:45 SC-2 local0.warn osafimmnd[406]: WA Spurious and redundant
ccb-apply request ignored ccbId:5
diff --git a/osaf/services/saf/immsv/immpbed/immpbe.cc
b/osaf/services/saf/immsv/immpbed/immpbe.cc
--- a/osaf/services/saf/immsv/immpbed/immpbe.cc
+++ b/osaf/services/saf/immsv/immpbed/immpbe.cc
@@ -33,9 +33,13 @@
static void saImmOmAdminOperationInvokeCallback(SaInvocationT invocation,
SaAisErrorT operationReturnValue,
- SaAisErrorT)
+ SaAisErrorT err)
{
- LOG_ER(Unexpected async admin-op callback invocation:%llx,
invocation);
+ if(invocation == 1) {
+ LOG_IN(Admop for aborting CCBs result: %u, immsv returned %u,
operationReturnValue, err);
+ } else {
+ LOG_ER(Unexpected async admin-op callback invocation:%llx,
invocation);
+ }
}
static const SaImmCallbacksT callbacks = {
@@
Re: [devel] [PATCH 1 of 1] IMM: Correction to support for admin-op for aborting non critical ccbs [#1107]
Ack from me.
Reviewed, but not tested.
Best regards,
Zoran
-Original Message-
From: Anders Björnerstedt
Sent: Wednesday, May 20, 2015 11:57 PM
To: reddy.neelaka...@oracle.com; Zoran Milinkovic
Cc: opensaf-devel@lists.sourceforge.net
Subject: [PATCH 1 of 1] IMM: Correction to support for admin-op for aborting
non critical ccbs [#1107]
osaf/services/saf/immsv/immnd/ImmModel.cc | 34 --
1 files changed, 23 insertions(+), 11 deletions(-)
The original fix only worked for aborting CCBs where there was an OI
actively involved in processing a ccb callback at the time of the admin-op.
It did not work for the case where the CCB was currently idle, i.e. waiting
for the next operation from the om-client and OIs waiting for the next
callback corrsponding to the next om-request.
diff --git a/osaf/services/saf/immsv/immnd/ImmModel.cc
b/osaf/services/saf/immsv/immnd/ImmModel.cc
--- a/osaf/services/saf/immsv/immnd/ImmModel.cc
+++ b/osaf/services/saf/immsv/immnd/ImmModel.cc
@@ -351,7 +351,7 @@ struct CcbInfo
SaAisErrorT mVeto; //SA_AIS_OK as long as no participan voted
error.
time_tmWaitStartTime;
SaUint32T mOpCount;
-SaUint32T mPbeRestartId;
+SaUint32T mPbeRestartId; /* ImplId for new PBE to resolve CCBs in
critical */
ImplementerSetmLocalAppliers;
ImmsvAttrNameList* mErrorStrings;/*Error strings generated by current op */
AugCcbParent* mAugCcbParent;
@@ -5634,7 +5634,19 @@ ImmModel::ccbAbort(SaUint32T ccbId, Conn
*client = ccb-mOriginatingConn;
ccb-mState = IMM_CCB_ABORTED;
-ccb-mVeto = SA_AIS_ERR_FAILED_OPERATION;
+if(ccb-mVeto == SA_AIS_OK) {
+/* An abort of a CCB currently not vetoed is most likely due to
+ either OI-timeout, or explicit abort by the om-client, or
+ abort by special admin-operation. All such cases must be
+ regarded as a resource error rather than a validation error.
+ Only an explicit reject of a ccb from an OI can be defined as
+ a validation error. Explicit abort by om-client or admin-op is
+ not really any error at all, but mVeto should not be SA_AIS_OK.
+*/
+ccb-mVeto = SA_AIS_ERR_NO_RESOURCES;
+setCcbErrorString(ccb, Resource Error: CCB abort due to either
+OI timeout or explicit abort request.);
+}
ccb-mWaitStartTime = 0;
@@ -12504,10 +12516,12 @@ ImmModel::cleanTheBasement(InvocVector
}
uint32_t oi_timeout = ((*i3)-mState == IMM_CCB_CRITICAL) ?
DEFAULT_TIMEOUT_SEC : max_oi_timeout;
-if(((*i3)-mWaitStartTime
-(now - (*i3)-mWaitStartTime = (int)oi_timeout)) ||
-((*i3)-mPbeRestartId)) {
-if((*i3)-mPbeRestartId) {
+if(((*i3)-mWaitStartTime (now - (*i3)-mWaitStartTime =
(int)oi_timeout)) || /* normal timeout */
+ ((*i3)-mPbeRestartId) || /* CCB was critical when PBE
restarted = Must ask new PBE for outcome */
+ sAbortNonCriticalCcbs) /* Request to abort ALL non critical
CCBs */
+{
+if((*i3)-mPbeRestartId)
+{
oi_timeout = 0;
TRACE_5(PBE restarted id:%u with ccb:%u in critical,
(*i3)-mPbeRestartId, (*i3)-mId);
@@ -12515,15 +12529,11 @@ ImmModel::cleanTheBasement(InvocVector
oi_timeout = 0;
TRACE_5(CCB %u timeout while waiting on implementer
reply,
(*i3)-mId);
-setCcbErrorString(*i3, Resource Error: CCB timeout while
- waiting on implementer reply);
}
if(sAbortNonCriticalCcbs) {
LOG_NO(CCB %u aborted by: immadm -o %u
safRdn=immManagement,safApp=safImmService,
(*i3)-mId, SA_IMM_ADMIN_ABORT_CCBS);
-setCcbErrorString(*i3, Resource Error: CCB aborted by
admin-operation
- '%u' on safRdn=immManagement,safApp=safImmService,
SA_IMM_ADMIN_ABORT_CCBS);
}
if((*i3)-mState == IMM_CCB_CRITICAL) {
@@ -12543,7 +12553,9 @@ ImmModel::cleanTheBasement(InvocVector
ccbsStuck=1;
}
} else if(!oi_timeout) {
-// oi_timeout set to 0 means that the ccb should be added
to the vector
+/* oi_timeout set to 0 means that the ccb should be added
to the vector.
+ CCB will be aborted only after the global abort
generated here by the coord
+ arrives back over fevs.*/
ccbs.push_back((*i3)-mId); /*Non critical ccb to abort.*/
}
}
--
One dashboard for servers and
