Please see inline. Thanks, Praveen On 22-Jul-13 7:42 PM, opensaf dev wrote: > 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? > For this each component should belong to different comptype. In such a case saAmfCtRelPathInstantiateCmd will be different for each component. There is no corresponding attribute in component class. But in a running system this still can achieved by changing the comptype attribute of component by a new comptype. In case a single comptype configured for several components, one thing still can be done by configuring saAmfCompInstantiateCmdArgv different for each component in component class. In this case instantiated script can include a switch to invoke particular binary based on the value of saAmfCompInstantiateCmdArgv. > 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. > See ticket #353. CSIAttributeValues can be modified without locking SI. other than that I am not ware of any method. > Thanks > Dev > > > > On Mon, Jul 22, 2013 at 4:11 AM, praveen malviya > <[email protected] <mailto:[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 > _______________________________________________ > Opensaf-users mailing list > [email protected] > <mailto:[email protected]> > 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
