We could use "safSu=SuT_OpSaf_CPND" or something even shorter to distinguish I
guess ... (but not OS that would be too confusing :-) ...)
Sayan
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Gudipalli S.-G19449
Sent: Monday, October 15, 2007 9:10 AM
To: Ingvar Bergström; [email protected]
Subject: Re: [Users] saAmfSUSITableEntry not empty after LOCK
Hi,
1) is a easy option to do but there is a catch. The SNMP index can't
be longer than 128 bytes, now if we increase the SU name the component name
will become very big. This will cause the entries in the
saAmfSCompCsiTable table to be not accessible as they will be larger than 128.
So we
had to keep the names to the smallest possible. We still can maybe have
a unique marker for openSAF SUs which is small, that should
solve the problem.
Regards
Sugadeesh
________________________________
From: Ingvar Bergström [mailto:[EMAIL PROTECTED]
Sent: Monday, October 15, 2007 3:34 PM
To: Gudipalli S.-G19449; [email protected]
Subject: RE: [Users] saAmfSUSITableEntry not empty after LOCK
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
