Re: [devel] [PATCH 0 of 1] Review Request for amfd: Return SA_AIS_ERR_BAD_OPERATION if error occurs during si-swap [#214]
Ack. Thanks, Praveen On 27-Nov-13 2:57 PM, nagendr...@oracle.com wrote: Summary: amfd: Return SA_AIS_ERR_BAD_OPERATION if error occurs during si-swap [#214] Review request for Trac Ticket(s): #214 Peer Reviewer(s): Hans F, Hans N Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE Affected branch(es): All 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): - EXPLAIN/COMMENT THE PATCH SERIES HERE changeset e4673201df894f6e8052031c82f19720ab157196 Author: Nagendra Kumarnagendr...@oracle.com Date: Wed, 27 Nov 2013 14:51:22 +0530 amfd: Return SA_AIS_ERR_BAD_OPERATION if error occurs during si-swap [#214] During si-swap, when su goes into terminating state, amf need to respond back to imm with error as SA_AIS_ERR_BAD_OPERATION. As of now, Amf is not even responding to imm in case of error during si-swap. This causes Amf to respond back to previous si operation result when another si-swap operation is successfully executed as invocation is not reset for previous si-swap operation. Complete diffstat: -- osaf/services/saf/amf/amfd/sg_2n_fsm.cc | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) Testing Commands: - In amf demo application, configure two SI (with two csi) with si dep. SU with two components. 1. Unlock both the SUs, SU1 Act, SU2 Standby. 2. Keep gdb in component in SU1 at saAmfResponse and Run 'amf-adm si-swap safSi=AmfDemo,safApp=AmfDemo1' 3. Return 21 in saAmfResponse from component in SU1 in gdb. 4. Run 'amf-adm si-swap safSi=AmfDemo1,safApp=AmfDemo1' Testing, Expected Results: -- After 3, si-swap command will return with SA_AIS_ERR_BAD_OPERATION. After 4, si-swap command will be successful and swap result will be sent for safSi=AmfDemo1,safApp=AmfDemo1 and not for safSi=AmfDemo,safApp=AmfDemo1(as it use to do it before this fix). Conditions of Submission: - Ack from peer reviewers 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
Re: [devel] [PATCH 0 of 1] Review Request for amfd: Reject admin op if csi add/remove is in progress [#627]
Ack. Thanks, Praveen On 14-Nov-13 5:11 PM, nagendr...@oracle.com wrote: Summary: amfd: Reject admin op if csi add/remove is in progress [#627] Review request for Trac Ticket(s): #627 Peer Reviewer(s): Hans F, Hans N Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE Affected branch(es): All Development branch: 4.3.x 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): - EXPLAIN/COMMENT THE PATCH SERIES HERE changeset ce1ede2aa0d1954e885e5a471ab8355a7ee4512f Author: Nagendra Kumarnagendr...@oracle.com Date: Thu, 14 Nov 2013 17:08:09 +0530 amfd: Reject admin op if csi add/remove is in progress [#627] Complete diffstat: -- osaf/services/saf/avsv/avd/avd_csi.c | 18 ++ osaf/services/saf/avsv/avd/avd_sg.c | 7 +++ osaf/services/saf/avsv/avd/avd_si.c | 7 +++ osaf/services/saf/avsv/avd/avd_su.c | 8 osaf/services/saf/avsv/avd/include/avd_csi.h | 1 + 5 files changed, 41 insertions(+), 0 deletions(-) Testing Commands: - immcfg -d safCsi=AmfDemo1,safSi=AmfDemo,safApp=AmfDemo1 amf-adm lock safSu=SU2\,safSg=AmfDemo\,safApp=AmfDemo1 Testing, Expected Results: -- Lock command gets TRY again and when csi add succeeds, Admin commands is honoured Conditions of Submission: - Ack from peer maintainers 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. -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
Re: [devel] [PATCH 0 of 1] Review Request for amfnd: Reboot payload when link between Controller and Payload flickers [#600]
Ack. Thanks Praveen On 20-Nov-13 3:23 PM, nagendr...@oracle.com wrote: Summary: amfnd: Reboot payload when link between Controller and Payload flickers [#600] Review request for Trac Ticket(s): #600 Peer Reviewer(s): hans.fe...@ericsson.com, hans.nordeb...@ericsson.com, mathi.naic...@oracle.com Pull request to: LIST THE PERSON WITH PUSH ACCESS HERE Affected branch(es): All 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): - EXPLAIN/COMMENT THE PATCH SERIES HERE changeset be6a7a288913b548dac28e16e8bc1c75f10bc2a2 Author: Nagendra Kumarnagendr...@oracle.com Date: Wed, 20 Nov 2013 15:19:00 +0530 amfnd: Reboot payload when link between Controller and Payload flickers [#600] If AvD Adest UP comes after AvD Down, this means that link has been reset between controller and payload. If data verify messages comes after AvD Adest down and then AvD Adest Up comes, this means that it is a case of contorller failover. This patch marks a flag when Amfnd receives AvD Adest Down and Reset the flag when it gets Data Verify message during failover. If AvD Adest UP comes after Data verify message, then Amfnd doesn;t take any action in this context. But if AvD Adest Up comes just after AvD Adest Down, then Amfnd reboots itself. We have solved the problem of link flickering between Act controller and Payload. Still problem of TIPC link flickering among controllers remains the concerns. During testing of this patch, we had seen problem in controllers and cluster reset. This patch doesn't solve the problem of cluster reset because of TIPC link flickering between the controllers. Complete diffstat: -- osaf/services/saf/amf/amfnd/di.cc | 20 osaf/services/saf/amf/amfnd/evt.cc | 4 +++- osaf/services/saf/amf/amfnd/include/avnd_cb.h | 1 + osaf/services/saf/amf/amfnd/include/avnd_evt.h | 1 + osaf/services/saf/amf/amfnd/mds.cc | 15 ++- osaf/services/saf/amf/amfnd/verify.cc | 2 ++ 6 files changed, 33 insertions(+), 10 deletions(-) Testing Commands: - Reset the link between Act controller and payload. Testing, Expected Results: -- Payload should reboot. Conditions of Submission: - Time out after 3 days. 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
[devel] Build problem in AMFD
Hi! I get the following build problem with the latest on the default branch: sg.cc: In function ‘void sg_admin_op_cb(SaImmOiHandleT, SaInvocationT, const SaNameT*, SaImmAdminOperationIdT, const SaImmAdminOperationParamsT_2**)’: sg.cc:1084:17: error: ‘rc’ was not declared in this scope regards, Anders Widell -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
Re: [devel] Build problem in AMFD
Sorry, I will fix it. -Nagu -Original Message- From: Anders Widell [mailto:anders.wid...@ericsson.com] Sent: 06 December 2013 17:50 To: Nagendra Kumar Cc: opensaf-devel@lists.sourceforge.net Subject: Build problem in AMFD Hi! I get the following build problem with the latest on the default branch: sg.cc: In function 'void sg_admin_op_cb(SaImmOiHandleT, SaInvocationT, const SaNameT*, SaImmAdminOperationIdT, const SaImmAdminOperationParamsT_2**)': sg.cc:1084:17: error: 'rc' was not declared in this scope regards, Anders Widell -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
Re: [devel] [PATCH 11 of 16] base: Removed unused macros from ncs_osprm.h, ncssysf_def.h and os_defs.h files [#537]
I get the following build error in PLM:
plms_dbg_utils.c: In function ‘plms_cb_dump_routine’:
plms_dbg_utils.c:50:2: error: implicit declaration of function
‘m_GET_ASCII_DATE_TIME_STAMP’ [-Werror=implicit-function-declaration]
regards,
Anders Widell
2013-12-05 13:51, ramesh.bet...@oracle.com skrev:
osaf/libs/agents/saf/cpa/cpa_init.c |2 +-
osaf/libs/agents/saf/mqa/mqa_init.c |2 +-
osaf/libs/agents/saf/plma/plma_init.c |2 +-
osaf/libs/core/include/ncs_osprm.h| 26 +
osaf/libs/core/include/ncssysf_def.h | 103
+
osaf/libs/core/include/os_defs.h | 48 +-
osaf/libs/core/leap/sysf_def.c| 122
osaf/libs/core/mds/include/mds_dt.h |1 -
osaf/services/infrastructure/dtms/dtm/dtm_intra.c |1 -
osaf/services/infrastructure/dtms/include/dtm.h |1 -
osaf/services/saf/cpsv/cpd/cpd_main.c |2 +-
osaf/services/saf/cpsv/cpnd/cpnd_main.c |2 +-
osaf/services/saf/mqsv/mqd/mqd_main.c |2 +-
osaf/services/saf/mqsv/mqnd/mqnd_main.c |2 +-
14 files changed, 14 insertions(+), 302 deletions(-)
diff --git a/osaf/libs/agents/saf/cpa/cpa_init.c
b/osaf/libs/agents/saf/cpa/cpa_init.c
--- a/osaf/libs/agents/saf/cpa/cpa_init.c
+++ b/osaf/libs/agents/saf/cpa/cpa_init.c
@@ -297,7 +297,7 @@ unsigned int ncs_cpa_startup(void)
osaf_mutex_unlock_ordie(s_agent_startup_mutex);
return m_LEAP_DBG_SINK(NCSCC_RC_FAILURE);
} else {
- m_NCS_DBG_PRINTF(\nCPSV:CPA:ON);
+ printf(\nCPSV:CPA:ON);
cpa_use_count = 1;
}
diff --git a/osaf/libs/agents/saf/mqa/mqa_init.c
b/osaf/libs/agents/saf/mqa/mqa_init.c
--- a/osaf/libs/agents/saf/mqa/mqa_init.c
+++ b/osaf/libs/agents/saf/mqa/mqa_init.c
@@ -988,7 +988,7 @@ unsigned int ncs_mqa_startup(void)
osaf_mutex_unlock_ordie(s_agent_startup_mutex);
return m_LEAP_DBG_SINK(NCSCC_RC_FAILURE);
} else {
- m_NCS_DBG_PRINTF(\nMQSV:MQA:ON);
+ printf(\nMQSV:MQA:ON);
mqa_use_count = 1;
}
diff --git a/osaf/libs/agents/saf/plma/plma_init.c
b/osaf/libs/agents/saf/plma/plma_init.c
--- a/osaf/libs/agents/saf/plma/plma_init.c
+++ b/osaf/libs/agents/saf/plma/plma_init.c
@@ -355,7 +355,7 @@ uint32_t ncs_plma_startup()
return m_LEAP_DBG_SINK(NCSCC_RC_FAILURE);
}else{
/** Initialize the library for the first time */
- m_NCS_DBG_PRINTF(\nPLMSV:PLMA:ON);
+ printf(\nPLMSV:PLMA:ON);
plma_use_count = 1;
}
osaf_mutex_unlock_ordie(s_agent_startup_mutex);
diff --git a/osaf/libs/core/include/ncs_osprm.h
b/osaf/libs/core/include/ncs_osprm.h
--- a/osaf/libs/core/include/ncs_osprm.h
+++ b/osaf/libs/core/include/ncs_osprm.h
@@ -143,22 +143,15 @@ extern C {
} NCS_OS_TASK_REQUEST;
/
-
-
-
- ****
**
**
** Lock Interface Primitives
**
**
**
** This interface is used by the client to control access to data or
**
- ** other shared resources. The interface utilizes the typedef NCS_OS_LOCK
**
- ** for processing object access requests. The NCS_OS_LOCK typedef is
**
+ ** other shared resources. The interface utilizes the typedef NCS_OS_LOCK **
+ ** for processing object access requests. The NCS_OS_LOCK typedef is **
** DEFINED BY THE TARGET SYSTEM in any manner necessary to carry the
**
** information needed to implement the interface.
**
**
**
-
-
-
***/
/
@@ -805,21 +798,6 @@ uint32_t ncs_os_posix_mq(NCS_OS_POSIX_MQ
/
#define
Re: [devel] [PATCH 0 of 3] Review Request for IMM: Implementation of NO_DANGLING flag [#49]
Also a commit message should start with a verb in present tense, add, fix,
remove, delete etc
-Original Message-
From: Anders Bjornerstedt [mailto:anders.bjornerst...@ericsson.com]
Sent: den 6 december 2013 15:33
To: Zoran Milinkovic
Cc: opensaf-devel@lists.sourceforge.net
Subject: Re: [devel] [PATCH 0 of 3] Review Request for IMM: Implementation of
NO_DANGLING flag [#49]
Hi Zoran.
Server side patch looks much better :-)
I still have some detail comments though.
Not all of them in this mail, but just to let you process some of them
in parallel with me and Neel continuing
the review, I send you these comments now.
1) Please make sure that the commit slogan for these change-sets are
prefixed with 'IMM: ' or 'IMMTOOLS:'.
Also skip starting the slogan proper with a redundant 'IMM':
Example:
IMM: IMM service implementation of NO_DANGLING flag [#49]
should be:
IMM: Service implementation of NO_DANGLING flag [#49]
It looks almost correct in the review request mail message subject line.
But the patch slogan is sometimes incorrect.
The patch slogan is the more important since it will become part of the
changset history.
---
2) I think you should inline ImmAttrMultiValue::getNextAttrValue()
same way as ImmAttrValue::empty() const is inline in the .hh file.
ImmAttrMultiValue* getNextAttrValue() const {return mNext;}
This call is used in iterating through a multi-values so its lilely to
be in tight loops.
--
3) I think we should rename sReverseRefObjectMMap to
sReverseNoDanglingObjectMMap
Please also move down the comment explaining this data-structure to be
below the structure,
not before it. This seems to be the dominating convention in this file
and since this comment
appears directly between two data-structures, it becomes unclear which
one is referred to.
The alternative is to have a blank line before the comment and after the
data-structure so that
both become associated by proximity to each other and separation from
the rest.
-
4) We need to allow NO_DANGLING on RDN attributes.
I suggest we fix this as a separate defect ticket. So in class-create we
need to remove the check
that ends up with:
LOG_NO(ERR_INVALID_PARAM: RDN '%s' cannot have NO_DANGLING flag,
The reason NO_DANGLING should be allowed on RDN attributes of CONFIG
objects is
to make referential integrity checking possible for association objects.
The other checks are correct though.
Runtime objects cannot have no-dangling and attribute type must be SaNameT.
In the next OpensAF release we will hopefully be moving away from
SaNameT, replacing it with
SaStringT as the physical type, plus a new IMM_ATTR flag to indicate
that the value is a DN.
When/if that happens, the no-dangling class-create checks need to be
updated to accept that new
kind of reference declaration.
--
5) In ImmModel::notCompatibleAtt
In the loop specific for no-dangling chjecks, you iterate through the
extent of a class and for each
object this if statement is executed:
ImmAttrValueMap::iterator avmi =
(*osi)-mAttrValueMap.find(attName);
if(avmi == (*osi)-mAttrValueMap.end())
continue;
It makes no sense to continue the iteration here. I would suggest
instead an osafassert.
If anattribute exists in a class then in the OpensAF implementation of
the IMM this means
that *all* instances of that class have the attribute defined. Now this
is an upgrade, so
we need to be wary of the case whn an attribute is added in a new class
version.
But this wntire section of code is guarded by
/* changedAttrs != NULL ensures that this check is only for
the schema update */
So we know that the attribute exists in both new and old version.
So replace the if statetement with:
osafassert(avmi != (*osi)-mAttrValueMap.end());
6) In ImmModel::notCompatibleAtt
This syslog warning:
LOG_WA(Object has a NO_DANGLING reference to a non-existing
object);
I think should rather say:
LOG_WA(Object %s attribute %s has a reference to a
non-existing object %s
schema change to add NO_DANGLING not
possible, .);
--
7) Still in notCompatibleAtt
This syslog warning:
LOG_WA(Object cannot have a NO_DANGLING reference to a
non-persistent runtime object);
should provide a bit more info:
LOG_WA(Object %u attribute %s has a reference to a
Re: [devel] [PATCH 1 of 3] IMM: API support for NO_DANGLING flag [#49]
Aren't the checks in imma redundant? The same ones seems to be done in the
server.
/Hans
-Original Message-
From: Zoran Milinkovic [mailto:zoran.milinko...@ericsson.com]
Sent: den 5 december 2013 16:05
To: reddy.neelaka...@oracle.com
Cc: opensaf-devel@lists.sourceforge.net
Subject: [devel] [PATCH 1 of 3] IMM: API support for NO_DANGLING flag [#49]
osaf/libs/agents/saf/imma/imma_om_api.c | 36 +--
osaf/libs/common/immsv/include/immpbe_dump.hh | 2 +-
osaf/libs/common/immsv/include/immsv_api.h| 9
osaf/libs/saf/include/Makefile.am | 3 +-
osaf/libs/saf/include/saImmOm_A_2_12.h| 2 +
osaf/libs/saf/include/saImmOm_A_2_13.h| 60
+++
osaf/libs/saf/libSaImm/Makefile.am| 2 +-
7 files changed, 106 insertions(+), 8 deletions(-)
IMM API support for reference integrity (NO_DANGLING flag)
diff --git a/osaf/libs/agents/saf/imma/imma_om_api.c
b/osaf/libs/agents/saf/imma/imma_om_api.c
--- a/osaf/libs/agents/saf/imma/imma_om_api.c
+++ b/osaf/libs/agents/saf/imma/imma_om_api.c
@@ -4173,7 +4173,7 @@ SaAisErrorT saImmOmClassCreate_2(SaImmHa
for (i = 0; attr != 0; attr = attrDefinitions[++i]) {
if (attr-attrName == NULL) {
TRACE(NULL attrName , not allowed.);
- TRACE_LEAVE();
+ TRACE_LEAVE();
return SA_AIS_ERR_INVALID_PARAM;
}
@@ -4181,21 +4181,47 @@ SaAisErrorT saImmOmClassCreate_2(SaImmHa
if(((attr-attrValueType != SA_IMM_ATTR_SANAMET )
(attr-attrValueType !=
SA_IMM_ATTR_SASTRINGT))) {
TRACE(ERR_INVALID_PARAM: RDN '%s' must be of
type SaNameT or SaStringT, attr-attrName);
- TRACE_LEAVE();
+ TRACE_LEAVE();
return SA_AIS_ERR_INVALID_PARAM;
}
if(attr-attrFlags SA_IMM_ATTR_MULTI_VALUE) {
TRACE(ERR_INVALID_PARAM: RDN '%s' can not be
multivalued, attr-attrName);
TRACE_LEAVE();
- return SA_AIS_ERR_INVALID_PARAM;
- }
+ return SA_AIS_ERR_INVALID_PARAM;
+ }
+
+ if(attr-attrFlags SA_IMM_ATTR_NO_DANGLING) {
+ TRACE(ERR_INVALID_PARAM: RDN '%s' can not have
NO_DANGLING flag, attr-attrName);
+ TRACE_LEAVE();
+ return SA_AIS_ERR_INVALID_PARAM;
+ }
+ }
+
+ if(attr-attrFlags SA_IMM_ATTR_NO_DANGLING) {
+ if(classCategory == SA_IMM_CLASS_RUNTIME) {
+ TRACE(ERR_INVALID_PARAM: NO_DANGLING attribute
'%s' cannot be defined for runtime class,
attr-attrName);
+ TRACE_LEAVE();
+ return SA_AIS_ERR_INVALID_PARAM;
+ }
+
+ if(attr-attrValueType != SA_IMM_ATTR_SANAMET) {
+ TRACE(ERR_INVALID_PARAM: Attribute '%s' is
flagged NO_DANGLING, must be of type SaNameT,
attr-attrName);
+ TRACE_LEAVE();
+ return SA_AIS_ERR_INVALID_PARAM;
+ }
+
+ if(attr-attrFlags SA_IMM_ATTR_RUNTIME) {
+ TRACE(ERR_INVALID_PARAM: Runtime attribute
'%s' cannot have NO_DANGLING flag, attr-
attrName);
+ TRACE_LEAVE();
+ return SA_AIS_ERR_INVALID_PARAM;
+ }
}
}
if (cb-is_immnd_up == false) {
TRACE_2(ERR_TRY_AGAIN: IMMND is DOWN);
-TRACE_LEAVE();
+ TRACE_LEAVE();
return SA_AIS_ERR_TRY_AGAIN;
}
diff --git a/osaf/libs/common/immsv/include/immpbe_dump.hh
b/osaf/libs/common/immsv/include/immpbe_dump.hh
--- a/osaf/libs/common/immsv/include/immpbe_dump.hh
+++ b/osaf/libs/common/immsv/include/immpbe_dump.hh
@@ -31,7 +31,7 @@
#define RELEASE_CODE 'A'
#define MAJOR_VERSION 2
-#define MINOR_VERSION 12
+#define MINOR_VERSION 13
/* Prototypes */
typedef std::mapstd::string, SaImmAttrFlagsT AttrMap;
diff --git a/osaf/libs/common/immsv/include/immsv_api.h
b/osaf/libs/common/immsv/include/immsv_api.h
--- a/osaf/libs/common/immsv/include/immsv_api.h
+++ b/osaf/libs/common/immsv/include/immsv_api.h
@@ -76,6 +76,15 @@ extern C {
#define OPENSAF_IMM_REPL_B_NAME @OpenSafImmReplicatorB
/* Used internally in the SaImmCcbFlagsT space to indicate that
+ a ccb currently contains at lest one operation that either
+ a) creates an object with no
