Philip Gwyn wrote:
On 18-Sep-2007 Peter Kruse wrote:
one thing that bothered me in the old apcmastersnmp was that
one could not configure the oids, they were hardcoded
as #defines, would it be possible to change that?
(I know, configuration files end in .c)

This one has the 2.x (AP9707) and 3.x (AP7600) OIDs hard-coded.  It is also
possible to define OIDs via configuration directives.

why don't you use the reset as well?  That is a feature of the pdu
that allows to configure the delay between off and on.  I really
think you should stick to that.

There are 2 reasons I didn't use the Reset command :

1- There are probably PDUs that don't have this feature.  They need to be
   supported (via the user-defined OIDs);

2- The code is currently structured that way.  It needs to see the outlet as
   "off" before turning it back on.  cf http://www.linux-ha.org/STONITH ("It
   must never report false positives for reset.");

Also, I'd like to point out that the delay between OFF and ON commands is user
configurable.  And that the default APC RESET delay isn't long enough to reboot
most of the BIOSes I've tried it with.
The reset command is the one required to be supported by a STONITH plugin - poweroff and poweron are optional. This may be a simulated reset (power off, wait, power on) but reset is required. The default for stonith-action is reboot, the other possibility is poweroff - I don't believe a plugin will ever be called with poweron unless invoked via the stonith command line. Please see http://www.linux-ha.org/ExternalStonithPlugins, it's the closest thing online for describing possible plugin actions - there is a mapping of external plugin operations to builtin plugin function calls and parameters.

Now you can certainly NOT support the reset request, but that would mean everyone using your new apcmastersnmp would have to configure stonith-action to be poweroff, lest they fail (or be surprised if you simply power off when a reset is requested).

It worked like this for some years now, and there was no problem at all with
it.

apcmastersnmp is incomplete.  It doesn't respect the ST_POWEROFF and ST_POWERON
commands.  Are there stats on the number of people who used apcmastersnmp,
discovered this problem and switched to apcmaster?

It would have been nice if it did support it, but, as I said above, ST_GENERIC_RESET is the required command.
Your argument that if the server needs to be resetted because
there is a problem with it, and therefore should not start
automatically I can not follow.  If the server boots after
a reset what harm can it do?

My understanding is that stonith is used when a node needs to be removed from
the cluster, for whatever reason.  Some of these reasons might be hardware
failure.  If it reboots right away, the hardware failure will not have been
fixed.
True, but if it is not a hardware issue (i.e. network hiccup) then a reset brings the node back. If a node cannot be contacted and fencing is setup properly, it will be stonith'd to prevent it from corrupting any shared resources - if it is a software issue (service crash, network, etc.) then your node could come back and resume its tasks if it is only reset, while poweroff certainly requires operator intervention. Of course, that's your call, but that is why the stonith actions is configurable. :-)
However, I am not a heartbeat guru.  I can easily be convinced that there are
situations this is adequate.

(Is Heartbeat going to replace the plugin with this one?)

It is my hope they will.

What firmware did you test your plugin with?

I have access to these PDUs :

APC Web/SNMP Management Card (MB:v3.8.6 PF:v3.3.4 PN:apc_hw02_aos_334.bin
AF1:v3.3.3 AN1:apc_hw02_rpdu_333.bin MN:AP7900 HR:B2
SN: ZA0722007382 MD:05/30/2007)

APC Web/SNMP Management Card (MB:v3.0.5 PF:v2.0.1 PN:aos201.bin AF1:v2.0.1
AN1:ms201.bin MN: AP9606 HR: G9 SN: WA0012008696 MD: 03/15/2000)


Please have a look at this thread:
http://lists.community.tummy.com/pipermail/linux-ha-dev/2007-April/014240.html

Will do.

-Philip

_______________________________________________________
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/


_______________________________________________________
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/

Reply via email to