[prev in list] [next in list] [prev in thread] [next in thread]
List: linux-ha-dev
Subject: RE: [Linux-ha-dev] Proposed Linux-HA SNMP Agent MIB Changes
From: "Zou, Yixiong" <yixiong.zou () intel ! com>
Date: 2004-10-19 17:05:59
Message-ID: 012676D607FCF54E986746512C22CE7D01E56C42 () orsmsx407
[Download RAW message or body]
Hi Konrad,
Your oppinions are excellent. I will incorporate them into the changes.
-----------------------------------
Yixiong Zou (yixiong.zou@intel.com)
All views expressed in this email are those of the individual sender.
>-----Original Message-----
>From: Konrad Rzeszutek [mailto:konradr@us.ibm.com]
>Sent: Tuesday, October 19, 2004 7:04 AM
>To: linux-ha-dev@lists.linux-ha.org
>Cc: Zou, Yixiong; General Linux-HA mailing list
>Subject: Re: [Linux-ha-dev] Proposed Linux-HA SNMP Agent MIB Changes
>
>Hey Zou,
>
>I have a couple of suggestions. Just scan this e-mail for the
>-> character.
>
>LHANodeIndex OBJECT-TYPE
>--> SYNTAX Integer32 (0..65535)
>You might want to make that a Textual Convention, considering that in
>LHACurrentNodeID you mention "This value is the same as the
>LHANodeIndex
>value of this node." and in LHACurrentNodeID you use
>Integer32 without
>putting a boundary condition as you are doing here. Other
>columnar nodes
>which are used as indices in other tables use similar values too -
>LHAIFIndex, LHAResourceGroupIndex, LHAMemberIndex
>
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> "An integer that uniquelly identifies a node in a cluster."
> ::= { LHANodeEntry 1 }
>
>LHANodeStatus OBJECT-TYPE
><-- SYNTAX DisplayString
>
>I know you mention that the status can be customized, hence
>you are not using
>an enumeration. But perhaps you should have another object- called
>LHANodeCustomizedStatus which is of string value and make this
>object a
>integer enumeration with undefined(0), init(1), up(2), ...,
>customized(6)?
>Also another thought - are the status bit-masked together? Would it be
>possible in HA world to have 'init | up | customized' at the
>same time? If so
>you might consider writting in the description that you would
>have all of
>those statuses seperated by some delimiter.
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The status of the node. For heartbeat, this would normally be
> init, up, active, or dead. Since the status can be
>customrized,
>
> it is defined as a DisplayString instead of an INTEGER."
> ::= { LHANodeEntry 4 }
>
>LHANodeUUID OBJECT-TYPE
> SYNTAX DisplayString
><-- DISPLAYHINT ?
>You might want to add a displayhint if the UUID is in some way
>structurized.
>Also is the UUID 255 or less? If it always is 32bytes consider
>using OCTET
>STRING(SIZE(32)) instead.
>
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The UUID of the current node."
><-- Perhaps some extra information - such as how to decipher that ?
> ::= { LHANodeEntry 5 }
>
>LHAIFStatus OBJECT-TYPE
> SYNTAX DisplayString
><-- Why not use an TruthValue or RowStatus. You mention in
>the description
>that it can only be dead or not. Why not change the name of
>this columnar
>node to LHAIFIsDead, make it a TruthValue? Or you can make it
>a RowStatus -
>with only two enumeration - active(1) and notInService(2).
>
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The status for this interface.
>
> NOTE WELL
>
> This is somewhat confusing as Linux-HA only reports if the
>heartbeat
> can be heard on that interfce or not. So for ethernet
>interfaces, the
> interfaces for the node itself is always dead as no heartbeat
>can be
> heard on that interface."
> ::= { LHAIFStatusEntry 3 }
>
>LHAResourceGroupStatus OBJECT-TYPE
> SYNTAX Integer32
><-- Since in the description you are mentioning that the valid
>values are from
>0 to 254, perhaps making this:
> SYNTAX Unsigned32(0..254)
>Would be more apt?
>
>Or you could make this an enumeration (keep in mind I'm adding
>+1, b/c the
>value zero in SNMP-world is always associated with 'undefined')
> SYNTAX INTEGER {
> undefined(0),
> running(1),
> deadButVarRunExist(2),
> deadButVarLockExist(3),
> stopped(4)
> }
>I'm not adding the rest of the enumerations - 4-100 , 150-199,
>and 200-254 b/c
>when those become available - you will have to update the MIB
>to reflect what
>they mean. When you do that, you could as well just expand the
>possible
>enumerations.
>
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The status of this resource group.
>
> 0 program is running
> 1 program is dead and /var/run pid file exists
> 2 program is dead and /var/lock lock file exists
> 3 program is stopped
> 4-100 reserved for future LSB use
> 100-149 reserved for distribution use
> 150-199 reserved for application use
> 200-254 reserved
>
> "
> ::= { LHAResourceGroupEntry 4 }
>
>
>LHAMemberAddress OBJECT-TYPE
> SYNTAX DisplayString
><-- Since this is an address (I presume IP-address?) why not
>use 'IpAddress'
>data type which is defined in SNMPv2-SMI? It looks like this:
>IpAddress ::=
> [APPLICATION 0]
> IMPLICIT OCTET STRING (SIZE (4))
>
>
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The address of the cluster member."
> ::= { LHAMembershipEntry 3 }
>
>
>LHAMemberLastChange OBJECT-TYPE
> SYNTAX INTEGER {
><-- You might want to add 'undefined(0)' just in case
>something goes havoc.
> nochange (1),
> joined (2),
> left (3)
> }
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "If this node is part of the membership or not."
> ::= { LHAMembershipEntry 6 }
>
>
>LHAHOPFudge OBJECT-TYPE
> SYNTAX DisplayString
><-- You mention in the description that this is the number of
>hops. Why not
>make it an Integer?
>
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The number of hops count minus the numer of nodes in cluster."
> ::= { LHAHeartbeatConfigInfo 2 }
>
>LHAKeepAlive OBJECT-TYPE
><-- SYNTAX DisplayString
><-- Should that be perhaps an Integer? The description makes
>me think of
>numbers.
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The heartbeat interval."
> ::= { LHAHeartbeatConfigInfo 3 }
>
>LHADeadTime OBJECT-TYPE
> SYNTAX DisplayString
><-- Why not use 'DateAndTime' textual convention, which is defined in
>SNMPv2-TC?
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The time it waits before declaring a node to be dead."
> ::= { LHAHeartbeatConfigInfo 4 }
>
>
>LHADeadPing OBJECT-TYPE
> SYNTAX DisplayString
><-- TimeStamp seems like an apt choice?
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The time it waits before declaring a ping node to be dead."
> ::= { LHAHeartbeatConfigInfo 5 }
>
>
>LHAWarnTime, LHAInitDead, LHAWatchdogTime - they all seem like
>'TimeStamp'
>syntax would be a better choice?
>
>The LHABaudRate and LHAUDPPort, perhaps they should be a
>number data type?
>
>LHNiceFailBack OBJECT-TYPE
> SYNTAX DisplayString
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
>
> "This is an obsolete option for the failback setting."
><-- I'm having problems understanding what that means?
> ::= { LHAHeartbeatConfigInfo 11 }
>
>LHAutoFailBack OBJECT-TYPE
> SYNTAX DisplayString
><-- Since in description you mentioned the possible options,
>why not make this
>an enumeration
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "Determins whether a resource will automatically fail back to
> its primary node, or remain on whatever the node is serving.
>
> Possible values are: on, off, legacy."
>
>
>LHAStonithHost OBJECT-TYPE
> SYNTAX DisplayString
><-- IpAddress syntax?
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "The STONITH host configured for this cluster."
> ::= { LHAHeartbeatConfigInfo 14 }
>
>LHARealTime OBJECT-TYPE
> SYNTAX DisplayString
><-- Can this be a number? Or do you intend to provide the user
>with values
>such as 'High", "Low", etc? If so, consider using an enumeration.
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "Realtime excution of heartbeat. High Priority, etc."
> ::= { LHAHeartbeatConfigInfo 17 }
>
>
>LHARTPriority - is that a duplicate of LHARealTime?
>
>LHADebugLevel and LHANormalPoll- seems like it should be a number?
>
>LHAAPIAuth - What kind of authentication information are you
>talking about?
>Keep in mind that the sub-agent might be running under a
>SNMPv1 daemon,
>meaning all of the traffic is in clear. Perhaps this might not
>be the best
>thing to expose?
>
>LHALogFile, LHADebugFile - you are using the texual convention
>'DisplayString'
>which is limited to 255 characters. I have seen paths to log
>files which is
>way more than 255 characters and also the OCTET STRING (from which
>DisplayString is derieved) is not limited to 255. Perhaps you
>should use a
>bigger size string octet?
>
>
>On Monday 18 October 2004 20:17, Zou, Yixiong wrote:
>> I had a very good chat with my colleague the other day about
>the current
>>
>> Linux-HA mib file. Basically I now realize that the current Linux-HA
>> mib
>> is not very script-friendly. It just shows how clueless I was when I
>> was
>> drafting the MIB.
>>
>> There are a couple things that are addressed this time:
>>
>> 1) A CurrentNodeID is added to the ClusterInfo group. This
>can be used
>> to determine the node id that this SNMP agent is running on.
>>
>> 2) A resourceGroupCount is added to the ClusterInfo group.
>This can be
>> used to determine how many resource group is currently configured.
>>
>> 3) The IFTable. Removed the nodename as one of the indexes in the
>> IFTable.
>> Because string is so much harder to parse and an nodeIndexID would be
>> enough.
>>
>> 4) The ResourceGroupTable is changed to so that the primary node name
>> is not part of the index. It will just be indexed by a number.
>>
>> below is the updated MIB. Again, feedbacks are welcome.
>>
>> -- Linux-HA: SNMP Subagent
>> --
>> -- Copyright (C) 2002 Yixiong Zou (yixiong.zou@intel.com)
>> --
>> -- This program is free software; you can redistribute it and/or
>> -- modify it under the terms of the GNU General Public License
>> -- as published by the Free Software Foundation; either version 2
>> -- of the License, or (at your option) any later version.
>> --
>> -- This program is distributed in the hope that it will be useful,
>> -- but WITHOUT ANY WARRANTY; without even the implied warranty of
>> -- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> -- GNU General Public License for more details.
>
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic