Hi, even if there is no major issue it is still confusing. There is not better to maintain lists of possible application SUs per node in a cluster. If OpenSAF components does not behave as "normal" components (from the operator view) it should be indicated which type of component each component is. To my opinion there are two solutions: 1) Give the OpenSAF SUs names which could easily be identified e.g.. safSu=SuT_OpenSaf_CPND. In such case the operator/script/program can easily see that there is no application SI left. 2) Remove OpenSAF SUs from the saAmfSUSITableEntry when the node is locked i.e let the OpenSAF components behave as normal application components to the operator. Regards Ingvar
________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gudipalli S.-G19449 Sent: den 15 oktober 2007 10:34 To: Ingvar Bergström; [email protected] Subject: Re: [Users] saAmfSUSITableEntry not empty after LOCK Hi, The operator can easily write a script for identifying the applications SUs on a node. I said SUs not SIs. The operator script need not track SIs, it needs to track only application SUs. He can easily search the SUSI table as you had done with this SU list to see that none have SI assignment. I don't see any major issue from scripting perspective, yes if he has to do manually then it is work. Regards Sugadeesh ________________________________ From: Ingvar Bergström [mailto:[EMAIL PROTECTED] Sent: Monday, October 15, 2007 12:33 PM To: Gudipalli S.-G19449; [email protected] Subject: RE: [Users] saAmfSUSITableEntry not empty after LOCK Hi, I suspected it was designed that way. I think it would be confusing for the operator to keep lists over SIs which are not excpected to move. It will be different lists for the two node types and possibly for different OpenSAF releases. Or (even worse) to keep lists over the applications SIs. This will also make it difficult to write scripts/programs helping the operator to perform different tasks in the cluster since the SI lists must be known to the script/program. Regards Ingvar ________________________________ From: Gudipalli S.-G19449 [mailto:[EMAIL PROTECTED] Sent: den 15 oktober 2007 08:29 To: Ingvar Bergström; [email protected] Subject: RE: [Users] saAmfSUSITableEntry not empty after LOCK Hi, It is by design that openSAF components are treated differently from application. All the AMF commands are applicable to application components and not to openSAF components(SG,SU). This is required, if openSAF goes OOS the node will become un manageable from openSAF perspective. The operator can get the list of all the application SUs on the node and verify that they all lost SI assignments to identify if the node lock is successful. Regards Sugadeesh ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ingvar Bergström Sent: Monday, October 15, 2007 11:35 AM To: [email protected] Subject: [Users] saAmfSUSITableEntry not empty after LOCK Hi, the saAmfSUSITableEntry will newer become empty after a LOCK operation. The "normal" SI's are moved away but the OpenSAF SI's are not (see the payload node example below). This will cause problems for e.g. the operator to decide when the node is locked since the saAmfSUSITableEntry is assumed to become emty. SC_2_1# snmpset -c public -v 2c localhost saAmfNodeAdminState.\"safNode=PL_2_3\" i 1 SC_2_1# snmpwalk -Os -c public -v 2c localhost saAmfSUSITableEntry.saAmfSUSISGName | grep safNode=PL_2_3 saAmfSUSISGName."safSu=SuT_CPND,safNode=PL_2_3"."safSi=Si_CPND5" = STRING: safSg=SG_CPND saAmfSUSISGName."safSu=SuT_IFND,safNode=PL_2_3"."safSi=Si_IFND5" = STRING: safSg=SG_IFND saAmfSUSISGName."safSu=SuT_NCS_PLD,safNode=PL_2_3"."safSi=Si_PLD6" = STRING: safSg=SG_NCS_ND_PLD Regards Ingvar
_______________________________________________ Users mailing list [email protected] http://list.opensaf.org/maillist/listinfo/users
