Thanks Praveen for the information. Appreciate if you could provide help clarifying these questions
1. Can I define instantiate script path per component in a SU ? If a SU contains, n components with each having different CLC scripts because of the nature of their services and dependencies, does IMM provides any way to mention CLC script relpath for every component? 2. How do we pass data to a HA active registered component/process during run time? Also, if a component is already assigned HA state as ACTIVE and after that when its running, is there a way through AMF to pass some parameters to this process? I have a scenario where I am required to interact with the active registered process, to add new service types dynamically which this can cater to newly.I am aware of the CSIAttributeValues which is available during setCSICallback but these parameters I believe are available only once to the Active process. Thanks Dev On Mon, Jul 22, 2013 at 4:11 AM, praveen malviya <[email protected] > wrote: > Please see inline. > Thanks > Praveen > > On 20-Jul-13 2:29 AM, opensaf dev wrote: > >> Hi, >> >> Appreciate if I get some directions or advise on what I might be possibly >> missing anything here while trying to add the new component of different >> type. >> >> Issue: Adding a new component type is fails loading nwayactive.xml with >> the >> below error mentioned in logs >> >> Scenario: >> I am trying to add an additional new type SA-Aware component to the >> n-wayactive.xml which provides different service. I realized that using a >> single component type defined by SaAmfCompType >> would restrict me to use different InstantiationLevel for this new >> component and a different instantiation script (for this 2nd type of >> component, which is used for a different service, >> hence have a different script with its own dependencies libs and like >> that..). So I planned to define a new SaAmfCompType and its related >> objects >> as listed below in IMM model to control >> the instation order and use different instation scripts. >> >> SaAmfCompBaseType >> SaAmfCSBaseType >> >> SaAmfCompType >> SaAmfCSType >> >> SaAmfSutCompType >> SaAmfSvcTypeCSTypes >> SaAmfCtCsType >> >> SaAmfComp >> SaAmfCompCsType >> SaAmfHealthcheck >> >> >> Logs: >> The problem is when I am trying to load immcfg -f nwayactive.xml, I get >> the >> below error. >> >> /var/log/messages: >> >> Jul 18 17:07:57 payload1 osafimmnd[44036]: WA Aborting ccb 2 while waiting >> for replies from implementers on COMPLETED >> Jul 18 17:07:57 payload1 osafimmnd[44036]: NO Ccb 2 ABORTED >> (immcfg_payload1_44143) >> >> Console output while try to run on payload node: >> [root@payload1 bin]# immcfg -f nwayactive_MultipleComponents.**xml >> Failed to apply object creations 21 >> [root@payload1 bin]# >> >> 1. Is there any way to get more logs/trace to debug IMM related issues to >> debug? Specifically I have seen multiple return codes like 12, 21 etc. Are >> they mapped to any enum in source. I have the source tar ball from source >> forge site with version 4.3.0. Could you please let me know where they are >> located. >> > You can see syslog messages. At the same time IMMND traces can also be > enabled. > One more method is there, there is tool (immxml-validate) to validate the > configuration. > Its location is same where we generate imm.xml. > > 2. Alternatively, I am also thinking to merge both my scripts together, >> then relative script path issue for two components >> with same compType will be fixed, but since they belongs to same compType, >> how do I mention a different instantiation level, >> to control the instatiation order? Is this feasible or the above approach >> of defining a new comp type for the 2nd component >> is better? I am trying to use n-way active redundancy model. >> > I think first configuration validation can be tried. > Component instantiation order can again be redefined in the individual > component in sAmfCompInstantiationLevel. > If defined, this value will never be replaced by the default value from > its comptype. Again > sAmfCompInstantiationLevel can be modified dynamically during run time > also. > > > 3. If I model two component to share the same SU, do I need to have a >> separate app.xml file for each component or a single >> file is enough for bunch of applications shared with many SUs and then >> merge with main imm.xml. Is it upto the user how she >> maintains the app.xml ? Which is better approach? >> > One can mention all components belonging to the same SU in a single > app.xml. > Typically app.xml will contain atleast one application which has atleast > on SG. > Please see AppConfig-2N.xml, for how a typical application looks like. > >> Thanks, >> Dev >> ------------------------------**------------------------------** >> ------------------ >> See everything from the browser to the database with AppDynamics >> Get end-to-end visibility with application monitoring from AppDynamics >> Isolate bottlenecks and diagnose root cause in seconds. >> Start your free trial of AppDynamics Pro today! >> http://pubads.g.doubleclick.**net/gampad/clk?id=48808831&iu=** >> /4140/ostg.clktrk<http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk> >> ______________________________**_________________ >> Opensaf-users mailing list >> Opensaf-users@lists.**sourceforge.net<[email protected]> >> https://lists.sourceforge.net/**lists/listinfo/opensaf-users<https://lists.sourceforge.net/lists/listinfo/opensaf-users> >> > > ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Opensaf-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensaf-users
