[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ha-dev
Subject:    Re: [Linux-ha-dev] Thoughts about the External plugin for release 2
From:       Lars Marowsky-Bree <lmb () suse ! de>
Date:       2005-03-15 18:05:25
Message-ID: 20050315180525.GD3858 () marowsky-bree ! de
[Download RAW message or body]

On 2005-03-15T06:41:57, Alan Robertson <alanr@unix.sh> wrote:

> Currently in the release 2 code, the external plugin gets launched with one 
> of the following parameters on the command line:
> 	status
> 	hostlist
> 	poweron
> 	poweroff
> 	reset
> 
> It has the following environment variables which might be set:
> 	ST_HOST
> telling it which host to STONITH.
> 
> Any command line arguments given to the command when it was configured are 
> transformed into ST_INFO_xx variables.  I don't know what that's about. 
> Maybe this is a misinterpretation of how we do other things related to OCF 
> resource agents.  But, since these aren't resource agents, I don't follow 
> the logic for why this was done.

The arguments for the STONITH script might include a login. Command line
arguments would show up in the ps output; environment variables will
not.

It's not actually a misinterpretation, but done for much the same
reasons ;-)

> I think something like this would be simpler and more intuitive:
> 	command-specified-to-run status
> 	command-specified-to-run hostlist
> 	command-specified-to-run reset hostname
> 	command-specified-to-run poweron hostname
> 	command-specified-to-run poweroff hostname
> 
> Where command-specified-to-run was the complete command which the user 
> specified they wanted to run - uninterpreted by anything else.  If it has 
> flags and options in the string, it has flags and options in the string. 
> Nothing would be added to the environment on account of this "command".

See above.

Also, this doesn't give us flexibility. The basic idea (already
anticipating the conversion to name/value pairs in the STONITH code, but
not touched in a while) was that external plugins could be just as
flexible to use as internal ones.

You're right that maybe there's a point to have commandline options _in
addition_ to name value pairs. But, I think this would be too complex;
better stick with one or the other.

It's by no means perfect yet.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business

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