Thanks Praveen for the information. I was looking for the below scenarios..
1. The main issue I am facing is, instead B gets assigned CSI first, A gets assigned first and then after A responds to setCSICallBack, B gets assigned CSI which is the reverse of what I was expecting. I can see all the classes and their association classes suggested are present in the IMM model. What could be the possible issue here? 2. I have defined two CSIs for components A and B and given the CSI dependencies, A depends on B's CSI assignment. What I have seen in the var/logs is safCsi=A gets assigned to component B and vice versa. This is confusing as I am trying to assign component A with safCsi=A and B with safCsi=B. This static binding between SaAmfCSI and SaAmfComp will also help in assigning new values to active CSI(to the registered component process) through modifying SaAmfCSIAttribute class. Can this direct binding between CSI as SaAmfCSI (not CSIType) and component as SaAmfComp possible? Appreciate if you can find possible issue with what is might not correct here. Thanks, Dev On Sun, Jul 28, 2013 at 9:35 PM, praveen malviya <[email protected] > wrote: > Please see inline. > Thanks, > Praveen > > On 29-Jul-13 6:44 AM, opensaf dev wrote: > >> Hi, >> >> In the below case CSI is not assigned properly. Could you help identifying >> the issue in the below case. >> >> I have two different sa-ware componets A and B belongs to SU1 in PL-1 with >> capability model x_active and y_standby belongs to >> same component type in a nway active redundancy model for which I have >> defined the CSIDependencies as below so that B is >> instantiated first then A. >> >> <object class="SaAmfCSI"> >> <dn>safCsi=A,safSi=AmfDemo,**safApp=AmfDemo2</dn> >> <attr> >> <name>saAmfCSType</name> >> <value>safVersion=1,safCSType=**AmfDemo2</value> >> </attr> >> <attr> >> <name>saAmfCSIDependencies</**name> >> <value>safCsi=B,safSi=AmfDemo,**safApp=AmfDemo2</value> >> </attr> >> </object> >> >> <object class="SaAmfCSI"> >> <dn>safCsi=B,safSi=AmfDemo,**safApp=AmfDemo2</dn> >> <attr> >> <name>saAmfCSType</name> >> <value>safVersion=1,safCSType=**AmfDemo2</value> >> </attr> >> </object> >> >> I expect that component A be assigned CSI after component B is >> CSIAssigned, >> however I see in /var/log/messages, that CSI assignments >> are reversed and A is assigned first then B is assigned. While debugging I >> came across these below queries, >> >> 1. If A and B belongs to a same compType, do I need to have SaAmfCSI >> object >> defined for every component that I am going to add in the SU or one >> SaAmfCSI is sufficient for both A and B even if I need to instantiate in a >> particular order? >> > In same SU one CSI will be assigned to one component only. If you have > more components and less CSIs then > some components will be instantiated but will not be assigned. Such > components are called spare components. > > 2. If one SaAmfCSI per component, then how to bind a CSI to the >> corresponding component. >> > For binding CSIs to components "objects of Association Classes (chpater 8 > B0401 spec)" are need to be defined . > From opensaf samples AppConfig-2N.xml: > > <object class="SaAmfCompCsType"> > <dn>safSupportedCsType=**safVersion=1\,safCSType=** > AmfDemo1,safComp=AmfDemo,**safSu=SU2,safSg=AmfDemo,**safApp=AmfDemo1</dn> > </object> > > but the association between cstype and comptype of this component should > also exists like below: > <object class="SaAmfCtCsType"> > <dn>safSupportedCsType=**safVersion=1\,safCSType=**AmfDemo1,safVersion=1,* > *safCompType=AmfDemo1</dn> > <attr> > <name>saAmfCtCompCapability</**name> > <value>1</value> > </attr> > </object> > > > > > 3. If SaAmfCSI is sufficient for A and B even if I need to instantiate in >> a >> particular order, then how do I mention the CSIDependencies in this case. >> > Since one csi goes to only one comp in the same SU, such things like a csi > depend on itself does not exist. > > Please help clarifying and suggesting the recommended changes needed in >> app.xml file to get the particular instantiation order among multiple >> components belonging to same >> compType in a service unit. >> > In components belong to same comptype achieve instantiation order by > defining saAmfCompInstantiationLevel for each components. > saAmfCompInstantiationLevel never > governs assignment of CSI, this attribute is only for instantiation of > components and not for assignment of CSIs in sa aware components. > >> 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
