[devel] [PATCH 1 of 1] osaf: Add definition of the new type SaConstStringT [#625]
osaf/libs/saf/include/Makefile.am| 1 +
osaf/libs/saf/include/saAis.h| 2 +
osaf/libs/saf/include/saAis_B_5_14.h | 39
3 files changed, 42 insertions(+), 0 deletions(-)
Add a definition of SaConstStringT as an OpenSAF extension to the AIS types.
The following example code illustrates a use case where SaConstStringT is
needed:
void foo(SaConstStringT s) {
printf("%s", s);
}
void bar(const char* s) {
foo(s);
}
By using SaConstStringT instead of SaStringT (or const SaStringT), we avoid
having to cast way the const qualifier of the string when calling foo() from
bar().
diff --git a/osaf/libs/saf/include/Makefile.am
b/osaf/libs/saf/include/Makefile.am
--- a/osaf/libs/saf/include/Makefile.am
+++ b/osaf/libs/saf/include/Makefile.am
@@ -20,6 +20,7 @@ MAINTAINERCLEANFILES = Makefile.in
include_HEADERS = \
saAis.h \
+ saAis_B_5_14.h \
saAmf.h \
saCkpt.h \
saCkpt_B_02_03.h \
diff --git a/osaf/libs/saf/include/saAis.h b/osaf/libs/saf/include/saAis.h
--- a/osaf/libs/saf/include/saAis.h
+++ b/osaf/libs/saf/include/saAis.h
@@ -179,5 +179,7 @@ typedef union {
}
#endif
+#include
+
#endif /* _SA_AIS_H */
diff --git a/osaf/libs/saf/include/saAis_B_5_14.h
b/osaf/libs/saf/include/saAis_B_5_14.h
new file mode 100644
--- /dev/null
+++ b/osaf/libs/saf/include/saAis_B_5_14.h
@@ -0,0 +1,39 @@
+/* -*- OpenSAF -*-
+ *
+ * (C) Copyright 2014 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
+ */
+
+/*
+ * DESCRIPTION:
+ * This file provides the suggested additions to the C language binding for
+ * the Service Availability(TM) Forum. It contains only the prototypes and
+ * type definitions that are part of this proposed addition. These additions
+ * are currently NON STANDARD. But the intention is to get these additions
+ * approved formally by SAF in the future.
+ */
+
+#ifndef _SA_AIS_B_5_14_H
+#define _SA_AIS_B_5_14_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+typedef const char* SaConstStringT;
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* _SA_AIS_B_5_14_H */
--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
___
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 osaf: Add definition of the new type SaConstStringT [#625]
Summary: osaf: Add definition of the new type SaConstStringT [#625]
Review request for Trac Ticket(s): 625
Peer Reviewer(s): Mathi
Pull request to:
Affected branch(es): default(4.5)
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 y
Samples n
Tests n
Other n
Comments (indicate scope for each "y" above):
-
changeset f2d124340ecbcb4cab0a16a66879b97fed9614ef
Author: Anders Widell
Date: Fri, 07 Mar 2014 14:45:22 +0100
osaf: Add definition of the new type SaConstStringT [#625]
Add a definition of SaConstStringT as an OpenSAF extension to the AIS
types.
The following example code illustrates a use case where SaConstStringT
is
needed:
void foo(SaConstStringT s) { printf("%s", s); }
void bar(const char* s) { foo(s); }
By using SaConstStringT instead of SaStringT (or const SaStringT), we
avoid
having to cast way the const qualifier of the string when calling foo()
from
bar().
Complete diffstat:
--
osaf/libs/saf/include/Makefile.am| 1 +
osaf/libs/saf/include/saAis.h| 2 ++
osaf/libs/saf/include/saAis_B_5_14.h | 39
+++
3 files changed, 42 insertions(+), 0 deletions(-)
Testing Commands:
-
Build and install OpenSAF. Compile the example code above using the header
files installed by OpenSAF.
Testing, Expected Results:
--
The example code should compile without warnings or errors.
Conditions of Submission:
-
Ack from Mathi
Arch Built StartedLinux distro
---
mipsn n
mips64 n n
x86 n n
x86_64 y 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.
--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=1
Re: [devel] SaAmfSIDependency problem
Praveen, Can you either post or send me privately the final imm.xml file? Alex From: praveen malviya [praveen.malv...@oracle.com] Sent: Friday, March 07, 2014 3:28 AM To: Alex Jones Cc: opensaf-devel@lists.sourceforge.net Subject: Re: [devel] SaAmfSIDependency problem Hi, I performed these steps with single controller on 4.3.1 and it worked fine: 1) immcfg -f <2N application> 2) immcfg -f 3) configure dependency with 2N SI as sponsor and NoRed SI as dependent. 3) unlock-in and unlock of all SUs. 4) immdump /etc/opensaf/imm.xml 5) Restart the controller 6) First sponsor was assigned and then dependent. Thanks Praveen On 05-Mar-14 9:40 PM, Alex Jones wrote: > Version is 4.3.1. > > 1) Create a 2N service group > 2) Create a "No Redundancy" service group > 3) Have one of the "No Redundancy" SIs depend on the 2N SI > 4) start opensaf > 5) The "No Redundancy" SI will get instantiated, but not get an > assignment. > > Alex > > On 03/05/2014 01:46 AM, praveen malviya wrote: >> Please specify which version of OpenSAF is being used. >> Also please tell the steps performed. >> >> Thanks, >> Praveen >> >> >> >> On 04-Mar-14 5:40 PM, Alex Jones wrote: >>> Hello All, >>> >>> I'm seeing a problem with SaAmfSIDependency when it is used >>> between >>> SIs in different SGs of different types. >>> >>> >>> safDepend=safSi=Management-2N\,safApp=ManagementApp,safSi=Management-NoRed2,safApp=ManagementApp >>> >>> >>> >>> In this declaration "Management-NoRed2" is in a "No Redundancy" >>> service group, and "Management-2N" is in a 2N service group. With this >>> declaration "Management-NoRed2" will never get an assignment. It gets >>> instantiated, but never gets an assignment. >>> >>> If I remove this declaration, "Management-NoRed2" gets its >>> assignment, but obviously the dependency isn't satisfied. >>> >>> If the dependency is between SIs of the same service group >>> type, it >>> works fine. >>> >>> >>> safDepend=safSi=Management-2N\,safApp=ManagementApp,safSi=FaultManagement-2N,safApp=FaultManagementApp >>> >>> >>> >>> In this example, these two SIs are in different SGs, but they are >>> both 2N. This case works as expected, and the dependency is satisfied. >>> >>> Is there a bug here, or am I missing some configuration? >>> Alex >>> >>> >>> -- >>> >>> Subversion Kills Productivity. Get off Subversion & Make the Move to >>> Perforce. >>> With Perforce, you get hassle-free workflows. Merge that actually >>> works. >>> Faster operations. Version large binaries. Built-in WAN >>> optimization and the >>> freedom to use Git, Perforce or both. Make the move to Perforce. >>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk >>> >>> ___ >>> Opensaf-devel mailing list >>> Opensaf-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >> >> > > -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
Re: [devel] [PATCH 1 of 1] osaf: Update the commit message template [#791]
HG: seems to be the comment prefix used by mercurial, but I agree it would look better with e.g. hash signs (#). I can change the script to use hash signs instead of HG:. Will add an example to the README file. / Anders Widell 2014-03-07 10:45, Mathivanan Naickan Palanivelu skrev: > Hi Anders, > > > Ack with the following comments: > > 1) Is it possible to avoid the "HG" prefix from each line in the editor? > > 2) Can we document in the README a good "example commit message" that follows > these guidelines. > > Thanks, > Mathi. > > >> Original Message >> Subject: [devel] [PATCH 1 of 1] osaf: Update the commit message >> template [#791] >> Date:Mon, 17 Feb 2014 17:44:16 +0100 >> From:Anders Widell >> To: , >> CC: opensaf-devel@lists.sourceforge.net >> >> tools/devel/review/00-README | 77 >> ++--- >> tools/devel/review/commit.template | 51 ++-- >> tools/devel/review/hgeditor.sh | 32 +++ >> 3 files changed, 91 insertions(+), 69 deletions(-) >> >> >> Update the commit message template with the agreeed format for how to >> write >> commit messages in OpenSAF. Add a shell script that can be used to set >> the >> default commit message in Mercurial to the commit message template. >> >> diff --git a/tools/devel/review/00-README >> b/tools/devel/review/00-README >> --- a/tools/devel/review/00-README >> +++ b/tools/devel/review/00-README >> @@ -1,79 +1,24 @@ >> Commit Message Format >> = >> >> -The patch review process heavily relies on properly formatted commit >> message. >> -This section will describe how commit message should be formatted and >> the >> -relation it has with the patch review process by email. >> - >> -A commit message should comply to the following template: >> - >> -* First line : 80-chars long one line short description (#ticket). >> Describe what >> -the patch is doing logically (not the bug >> description) >> -* Second line : Blank >> -* Third line+ : 80-chars long lines for a more complete description >> - >> --<-<-<-<-<- >> -example: this is a one line short description (#2000) >> - >> -This is a more elaborate description that explains your changes and >> the >> -original problem and how it got solved. >> - >> - * Blah >> - * Blah >> - >> -Signed-off-by: John Doe >> --<-<-<-<-<- >> - >> -The first line will be grabbed by the 'hg email' command and added as >> the >> -subject of the patch, hence the why it should be short and precise. >> Note that it >> -also contains the "area/module/feature" of the changes (i.e. >> example:). If you >> -have trouble identifying the unique nature of the patch, your patch >> is probably >> -way to long and should be divided in a series. >> - >> -The Ticket # in a future integration will be used on the Trac web >> interface to >> -correlate tickets and commits. It will also be used by Mercurial >> hooks to >> -close/fix tickets automatically if needed. >> - >> -The long description gives more details about the patch/changeset. >> - >> -The SOB tag is the original patch author. >> - >> +The patch review process heavily relies on properly formatted commit >> messages. >> +Use the file commit.template in this directory as a template when >> writing >> +commit messages. Make sure that your commit message contains all the >> necessary >> +parts, i.e. the component name, a short description, the ticket >> number and >> +a long description. >> >> Default Commit Message Template >> === >> >> -Apparently Mercurial lacks the support of customizing the default >> commit message >> -based on a template file somewhere in the repository. >> +Enter the following set of commands to set up the commit.template as >> the default >> +commit message in Mercurial (you need to log out and log in again for >> the change >> +to take effect): >> >> -The Qct extension can be installed and used in your ~/.hgrc profile >> to point to >> -a template file, so that you're nagged every time how to fill the >> commit >> -message properly ;) >> - >> -For instance under Red Hat/Fedora the package is called >> 'qct-mercurial' >> - >> - % yum install qct-mercurial >> - % yum install qct >> - >> -http://www.selenic.com/mercurial/wiki/index.cgi/QctExtension >> - >> -Under './tools/devel/review/commit.template', you'll find a default >> template that you >> -can use with the Qct extension. The extension automatically looks for >> a template >> -file under `hg root`/.commit.template, a copy is already placed in >> the OpenSAF >> -repository for developer that would like to use the Qct extension. >> - >> --<-<-<-<-<- >> -[extensions] >> -hgext.qct = >> - >> -[qct] >> -signoff = Signed-off-by: John Doe >> --<-<-<-<-<- >> - >> -To use the Qct Extension, you'll have to commit your changes using >> the '
Re: [devel] [PATCH 1 of 1] osaf: Update the commit message template [#791]
Hi Anders, Ack with the following comments: 1) Is it possible to avoid the "HG" prefix from each line in the editor? 2) Can we document in the README a good "example commit message" that follows these guidelines. Thanks, Mathi. > Original Message > Subject: [devel] [PATCH 1 of 1] osaf: Update the commit message > template [#791] > Date: Mon, 17 Feb 2014 17:44:16 +0100 > From: Anders Widell > To:, > CC: opensaf-devel@lists.sourceforge.net > > tools/devel/review/00-README | 77 > ++--- > tools/devel/review/commit.template | 51 ++-- > tools/devel/review/hgeditor.sh | 32 +++ > 3 files changed, 91 insertions(+), 69 deletions(-) > > > Update the commit message template with the agreeed format for how to > write > commit messages in OpenSAF. Add a shell script that can be used to set > the > default commit message in Mercurial to the commit message template. > > diff --git a/tools/devel/review/00-README > b/tools/devel/review/00-README > --- a/tools/devel/review/00-README > +++ b/tools/devel/review/00-README > @@ -1,79 +1,24 @@ > Commit Message Format > = > > -The patch review process heavily relies on properly formatted commit > message. > -This section will describe how commit message should be formatted and > the > -relation it has with the patch review process by email. > - > -A commit message should comply to the following template: > - > -* First line : 80-chars long one line short description (#ticket). > Describe what > -the patch is doing logically (not the bug > description) > -* Second line : Blank > -* Third line+ : 80-chars long lines for a more complete description > - > --<-<-<-<-<- > -example: this is a one line short description (#2000) > - > -This is a more elaborate description that explains your changes and > the > -original problem and how it got solved. > - > - * Blah > - * Blah > - > -Signed-off-by: John Doe > --<-<-<-<-<- > - > -The first line will be grabbed by the 'hg email' command and added as > the > -subject of the patch, hence the why it should be short and precise. > Note that it > -also contains the "area/module/feature" of the changes (i.e. > example:). If you > -have trouble identifying the unique nature of the patch, your patch > is probably > -way to long and should be divided in a series. > - > -The Ticket # in a future integration will be used on the Trac web > interface to > -correlate tickets and commits. It will also be used by Mercurial > hooks to > -close/fix tickets automatically if needed. > - > -The long description gives more details about the patch/changeset. > - > -The SOB tag is the original patch author. > - > +The patch review process heavily relies on properly formatted commit > messages. > +Use the file commit.template in this directory as a template when > writing > +commit messages. Make sure that your commit message contains all the > necessary > +parts, i.e. the component name, a short description, the ticket > number and > +a long description. > > Default Commit Message Template > === > > -Apparently Mercurial lacks the support of customizing the default > commit message > -based on a template file somewhere in the repository. > +Enter the following set of commands to set up the commit.template as > the default > +commit message in Mercurial (you need to log out and log in again for > the change > +to take effect): > > -The Qct extension can be installed and used in your ~/.hgrc profile > to point to > -a template file, so that you're nagged every time how to fill the > commit > -message properly ;) > - > -For instance under Red Hat/Fedora the package is called > 'qct-mercurial' > - > - % yum install qct-mercurial > - % yum install qct > - > -http://www.selenic.com/mercurial/wiki/index.cgi/QctExtension > - > -Under './tools/devel/review/commit.template', you'll find a default > template that you > -can use with the Qct extension. The extension automatically looks for > a template > -file under `hg root`/.commit.template, a copy is already placed in > the OpenSAF > -repository for developer that would like to use the Qct extension. > - > --<-<-<-<-<- > -[extensions] > -hgext.qct = > - > -[qct] > -signoff = Signed-off-by: John Doe > --<-<-<-<-<- > - > -To use the Qct Extension, you'll have to commit your changes using > the 'hg > -commit-tool | hg qct' command. The tool has neat features, like > dynamically > -deciding which files will be part of the current commit etc. But it > might bug > -some developers since it pops up a GUI. > - > +mkdir ~/bin > +cp hgeditor.sh ~/bin > +chmod 755 ~/bin/hgeditor.sh > +echo "export HGEDITOR=~/bin/hgeditor.sh" >> ~/.bashrc > +echo "setenv HGEDITOR ~/bin/hgeditor.sh" >> ~/.cshrc > > Mercurial Settings Needed for
[devel] [PATCH 0 of 1] Review Request for SMF #752
Summary: smfd: deletion of objects owned by SMF possible regadless of DN Review request for Trac Ticket(s): 752 Peer Reviewer(s): bertil Pull request to: Affected branch(es): 4.3, 4.4, default 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): - smfd: deletion of objects owned by SMF possible regadless of DN changeset fe18356894f2a8b2ccec8233dd2930657c5f7028 Author: Ingvar Bergstrom Date: Fri, 07 Mar 2014 09:59:19 +0100 smfd: deletion of objects owned by SMF possible regadless of DN [#752] SMF allows objects to be created and deleted regardless of DN. Without this patch the deletion of objects needed specific RDN to be accepted. Complete diffstat: -- osaf/services/saf/smfsv/smfd/SmfUtils.cc | 22 +++ osaf/services/saf/smfsv/smfd/SmfUtils.hh |8 + osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc | 380 ++--- 3 files changed, 244 insertions(+), 166 deletions(-) Testing Commands: - Testing, Expected Results: -- Conditions of Submission: - Arch Built StartedLinux distro --- mipsn n mips64 n n x86 n n x86_64 y y powerpc n n powerpc64 n n Reviewer Checklist: --- [Submitters: make sure that your review doesn't trigger any checkmarks!] Your checkin has not passed review because (see checked entries): ___ Your RR template is generally incomplete; it has too many blank entries that need proper data filled in. ___ You have failed to nominate the proper persons for review and push. ___ Your patches do not have proper short+long header ___ You have grammar/spelling in your header that is unacceptable. ___ You have exceeded a sensible line length in your headers/comments/text. ___ You have failed to put in a proper Trac Ticket # into your commits. ___ You have incorrectly put/left internal data in your comments/files (i.e. internal bug tracking tool IDs, product names etc) ___ You have not given any evidence of testing beyond basic build tests. Demonstrate some level of runtime or other sanity testing. ___ You have ^M present in some of your files. These have to be removed. ___ You have needlessly changed whitespace or added whitespace crimes like trailing spaces, or spaces before tabs. ___ You have mixed real technical changes with whitespace and other cosmetic code cleanup changes. These have to be separate commits. ___ You need to refactor your submission into logical chunks; there is too much content into a single commit. ___ You have extraneous garbage in your review (merge commits etc) ___ You have giant attachments which should never have been sent; Instead you should place your content in a public tree to be pulled. ___ You have too many commits attached to an e-mail; resend as threaded commits, or place in a public tree for a pull. ___ You have resent this content multiple times without a clear indication of what has changed between each re-send. ___ You have failed to adequately and individually address all of the comments and change requests that were proposed in the initial review. ___ You have a misconfigured ~/.hgrc file (i.e. username, email etc) ___ Your computer have a badly configured date and time; confusing the the threaded patch review. ___ Your changes affect IPC mechanism, and you don't present any results for in-service upgradability test. ___ Your changes affect user manual and documentation, your patch series do not contain the patch that updates the Doxygen manual. -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
[devel] [PATCH 1 of 1] smfd: deletion of objects owned by SMF possible regadless of DN [#752]
osaf/services/saf/smfsv/smfd/SmfUtils.cc | 22 +
osaf/services/saf/smfsv/smfd/SmfUtils.hh |8 +
osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc | 380 --
3 files changed, 244 insertions(+), 166 deletions(-)
SMF allows objects to be created and deleted regardless of DN.
Without this patch the deletion of objects needed specific RDN to be accepted.
diff --git a/osaf/services/saf/smfsv/smfd/SmfUtils.cc
b/osaf/services/saf/smfsv/smfd/SmfUtils.cc
--- a/osaf/services/saf/smfsv/smfd/SmfUtils.cc
+++ b/osaf/services/saf/smfsv/smfd/SmfUtils.cc
@@ -238,6 +238,28 @@ SmfImmUtils::classDescriptionMemoryFree(
}
//
--
+// getClassNameForObject()
+//
--
+bool
+SmfImmUtils::getClassNameForObject(const std::string& i_dn, std::string&
o_className)
+{
+SaImmAttrValuesT_2 **attributes;
+if (this->getObject(i_dn, &attributes) == false) {
+LOG_NO("Failed to get object %s", i_dn.c_str());
+return false;
+ }
+
+o_className = immutil_getStringAttr((const SaImmAttrValuesT_2
**)attributes,
+SA_IMM_ATTR_CLASS_NAME, 0);
+if (o_className.empty()) {
+LOG_NO("Failed to get class name for object %s", i_dn.c_str());
+return false;
+}
+
+ return true;
+}
+
+//
--
// getObject()
//
--
bool
diff --git a/osaf/services/saf/smfsv/smfd/SmfUtils.hh
b/osaf/services/saf/smfsv/smfd/SmfUtils.hh
--- a/osaf/services/saf/smfsv/smfd/SmfUtils.hh
+++ b/osaf/services/saf/smfsv/smfd/SmfUtils.hh
@@ -109,6 +109,14 @@ class SmfImmUtils {
bool classDescriptionMemoryFree(SaImmAttrDefinitionT_2 **
i_attributeDefs);
///
+/// Purpose: Get the class name for an IMM object.
+/// @param i_dn DN of the object to read the class name from.
+/// @param o_className Resulting class name
+/// @return True if successful, otherwise false
+///
+bool getClassNameForObject(const std::string& i_dn, std::string&
o_className);
+
+///
/// Purpose: Get all attributes for an IMM object.
/// @param i_dn DN of the object to get.
/// @param o_attributes Resulting attribute values
diff --git a/osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc
b/osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc
--- a/osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc
+++ b/osaf/services/saf/smfsv/smfd/smfd_campaign_oi.cc
@@ -49,6 +49,13 @@ static const SaImmClassNameT campaignCla
static const SaImmClassNameT smfConfigClassName = (SaImmClassNameT)
"OpenSafSmfConfig";
static const SaImmClassNameT smfSwBundleClassName = (SaImmClassNameT)
"SaSmfSwBundle";
+typedef enum {
+SMF_CLASS_UNKNOWN = 0,
+SMF_CLASS_CAMPAIGN = 1,
+SMF_CLASS_BUNDLE = 2,
+SMF_CLASS_CONFIG = 3
+} smf_classes_t;
+
/**
* Campaign Admin operation handling. This function is executed as an
* IMM callback.
@@ -184,187 +191,227 @@ static SaAisErrorT saImmOiCcbCompletedCa
}
/*
-** "check that the sequence of change requests contained in the CCB is
-** valid and that no errors will be generated when these changes
-** are applied."
-*/
+** "check that the sequence of change requests contained in the CCB is
+** valid and that no errors will be generated when these changes
+** are applied."
+*/
ccbUtilOperationData = ccbUtilCcbData->operationListHead;
while (ccbUtilOperationData != NULL) {
- switch (ccbUtilOperationData->operationType) {
- case CCBUTIL_CREATE:
- {
- //Handle the campaign object
- if
(strcmp(ccbUtilOperationData->param.create.className, campaignClassName) == 0) {
- SmfCampaign
test(ccbUtilOperationData->param.create.parentName,
-
ccbUtilOperationData->param.create.attrValues);
+switch (ccbUtilOperationData->operationType) {
+case CCBUTIL_CREATE:
+{
+//Handle the campaign object
+if
(strcmp(ccbUtilOperationData->param.create.className, campaignClassName) == 0) {
+SmfCampaign
test(ccbUtilOperationData->param.create.parentName,
+
ccbUtilOperationData->param.create.attrValues);
+//Save the class name enum for use in later
phases
+ccbUtilOperationData->userData =
(void*)SMF_CLASS_CAMPAIGN;
+
Re: [devel] SaAmfSIDependency problem
Hi, I performed these steps with single controller on 4.3.1 and it worked fine: 1) immcfg -f <2N application> 2) immcfg -f 3) configure dependency with 2N SI as sponsor and NoRed SI as dependent. 3) unlock-in and unlock of all SUs. 4) immdump /etc/opensaf/imm.xml 5) Restart the controller 6) First sponsor was assigned and then dependent. Thanks Praveen On 05-Mar-14 9:40 PM, Alex Jones wrote: > Version is 4.3.1. > > 1) Create a 2N service group > 2) Create a "No Redundancy" service group > 3) Have one of the "No Redundancy" SIs depend on the 2N SI > 4) start opensaf > 5) The "No Redundancy" SI will get instantiated, but not get an > assignment. > > Alex > > On 03/05/2014 01:46 AM, praveen malviya wrote: >> Please specify which version of OpenSAF is being used. >> Also please tell the steps performed. >> >> Thanks, >> Praveen >> >> >> >> On 04-Mar-14 5:40 PM, Alex Jones wrote: >>> Hello All, >>> >>> I'm seeing a problem with SaAmfSIDependency when it is used >>> between >>> SIs in different SGs of different types. >>> >>> >>> safDepend=safSi=Management-2N\,safApp=ManagementApp,safSi=Management-NoRed2,safApp=ManagementApp >>> >>> >>> >>> >>> In this declaration "Management-NoRed2" is in a "No Redundancy" >>> service group, and "Management-2N" is in a 2N service group. With this >>> declaration "Management-NoRed2" will never get an assignment. It gets >>> instantiated, but never gets an assignment. >>> >>> If I remove this declaration, "Management-NoRed2" gets its >>> assignment, but obviously the dependency isn't satisfied. >>> >>> If the dependency is between SIs of the same service group >>> type, it >>> works fine. >>> >>> >>> safDepend=safSi=Management-2N\,safApp=ManagementApp,safSi=FaultManagement-2N,safApp=FaultManagementApp >>> >>> >>> >>> >>> In this example, these two SIs are in different SGs, but they are >>> both 2N. This case works as expected, and the dependency is satisfied. >>> >>> Is there a bug here, or am I missing some configuration? >>> Alex >>> >>> >>> -- >>> >>> >>> Subversion Kills Productivity. Get off Subversion & Make the Move to >>> Perforce. >>> With Perforce, you get hassle-free workflows. Merge that actually >>> works. >>> Faster operations. Version large binaries. Built-in WAN >>> optimization and the >>> freedom to use Git, Perforce or both. Make the move to Perforce. >>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk >>> >>> >>> ___ >>> Opensaf-devel mailing list >>> Opensaf-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/opensaf-devel >> >> > > -- Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk ___ Opensaf-devel mailing list Opensaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensaf-devel
