...
> For example, in the case of the baytech, one device can reset multiple
> machines. I had sort of thought about one config file per device, but your
> idea below sounds nice.
>
> > I have a case wheresince the power controllers are serial
> > devices, the ability to power off a node must be assigned to a
> > specific machine. An external terminal server would be a nice
> > solution, but the budget doesn't allow it.
> >
> > What I was thinking of doing is having a config file format for this
> > device that looks like:
> >
> > #
> > # host_node node_to_kill serial_port
> > #
> > nodea nodeb /dev/ttyS1
> > nodeb nodea /dev/ttyS1
> > nodeb nodec /dev/ttyS2
>
> If you want to integrate this into heartbeat, then you might try this
> syntax:
>
> stonith type node parameters
> Where if node is '*', then all machines can do this. Otherwise, only the
> named machine can do it. This would then look like this:
> stonith typename nodea nodeb /dev/ttyS1
>
> For a baytech device, it would look like this:
> stonith baytech * ip-address login password
>
OK, What do you think about this?
/*
* st_setconfinfo - API entry point to process one line of config info
* for this particular device.
*
* Parse the config information in the given string, and stash it away...
*
* The expected format of the string is:
* "stonith" <type> <node> <parameters>
*
* The first 3 fields are common to all stonith types
*
* where "stonith" is a fixed string
* <type> should be the name of the stonith module to invoke.
* the fixed string "WTI_RPS10" for this object
* <node> should be the nodename of the machine this stonith device
* is accessible from as reported by sysinfo()
* (or uname -n), or * to indicate all nodes (let's say,
* if the device was accessible over the network)
*
* <parameters> are the parameters specific to this type of object
*
* The format of <parameters> for this module is:
* <serial device> <remotenode> <outlet> [<remotenode> <outlet>] ...
*
* e.g. A machine named 'nodea' can kill a machine named 'nodeb' through
* a device attached to serial port /dev/ttyS0.
* A machine named 'nodeb' can kill machines 'nodea' and 'nodec'
* through a device attached to serial port /dev/ttyS1 (outlets 0
* and 1 respectively)
*
* stonith nodea WTI_RPS10 /dev/ttyS0 nodeb 0
* stonith nodeb WTI_RPS10 /dev/ttyS0 nodea 0 nodec 1
*
* Another possible configuration is for 2 stonith devices accessible
* through 2 different serial ports on nodeb:
*
* stonith nodeb WTI_RPS10 /dev/ttyS0 nodea 0
* stonith nodeb WTI_RPS10 /dev/ttyS1 nodec 0
*/
I think there is something left to
be desired here... Maybe we do need a 'device name' as a part of the
fixed string, for the case when one machine has access to two
different stonith devices:
It looks like you aready have the concept of a 'device id' in baytech.c
So maybe it should be
The expected format of the string is:
"stonith" <devicename> <type> <node> <parameters>
e.g. (just like the last example in the commetns above)
stonith RPC1 nodea WTI_RPS10 /dev/ttyS0 nodeb 0
stonith RPC2 nodeb WTI_RPS10 /dev/ttyS0 nodea 0
stonith RPC3 nodeb WTI_RPS10 /dev/ttyS1 nodec 0
> For example, in the case of the baytech, one device can reset multiple
> machines. I had sort of thought about one config file per device, but your
> idea below sounds nice.
>
> > I have a case wheresince the power controllers are serial
> > devices, the ability to power off a node must be assigned to a
> > specific machine. An external terminal server would be a nice
> > solution, but the budget doesn't allow it.
> >
> > What I was thinking of doing is having a config file format for this
> > device that looks like:
> >
> > #
> > # host_node node_to_kill serial_port
> > #
> > nodea nodeb /dev/ttyS1
> > nodeb nodea /dev/ttyS1
> > nodeb nodec /dev/ttyS2
>
> If you want to integrate this into heartbeat, then you might try this
> syntax:
>
> stonith type node parameters
> Where if node is '*', then all machines can do this. Otherwise, only the
> named machine can do it. This would then look like this:
> stonith typename nodea nodeb /dev/ttyS1
>
> For a baytech device, it would look like this:
> stonith baytech * ip-address login password
>
OK, What do you think about this?
/*
* st_setconfinfo - API entry point to process one line of config info
* for this particular device.
*
* Parse the config information in the given string, and stash it away...
*
* The expected format of the string is:
* "stonith" <type> <node> <parameters>
*
* The first 3 fields are common to all stonith types
*
* where "stonith" is a fixed string
* <type> should be the name of the stonith module to invoke.
* the fixed string "WTI_RPS10" for this object
* <node> should be the nodename of the machine this stonith device
* is accessible from as reported by sysinfo()
* (or uname -n), or * to indicate all nodes (let's say,
* if the device was accessible over the network)
*
* <parameters> are the parameters specific to this type of object
*
* The format of <parameters> for this module is:
* <serial device> <remotenode> <outlet> [<remotenode> <outlet>] ...
*
* e.g. A machine named 'nodea' can kill a machine named 'nodeb' through
* a device attached to serial port /dev/ttyS0.
* A machine named 'nodeb' can kill machines 'nodea' and 'nodec'
* through a device attached to serial port /dev/ttyS1 (outlets 0
* and 1 respectively)
*
* stonith nodea WTI_RPS10 /dev/ttyS0 nodeb 0
* stonith nodeb WTI_RPS10 /dev/ttyS0 nodea 0 nodec 1
*
* Another possible configuration is for 2 stonith devices accessible
* through 2 different serial ports on nodeb:
*
* stonith nodeb WTI_RPS10 /dev/ttyS0 nodea 0
* stonith nodeb WTI_RPS10 /dev/ttyS1 nodec 0
*/
I think there is something left to
be desired here... Maybe we do need a 'device name' as a part of the
fixed string, for the case when one machine has access to two
different stonith devices:
It looks like you aready have the concept of a 'device id' in baytech.c
So maybe it should be
The expected format of the string is:
"stonith" <devicename> <type> <node> <parameters>
e.g. (just like the last example in the commetns above)
stonith RPC1 nodea WTI_RPS10 /dev/ttyS0 nodeb 0
stonith RPC2 nodeb WTI_RPS10 /dev/ttyS0 nodea 0
stonith RPC3 nodeb WTI_RPS10 /dev/ttyS1 nodec 0