[Linux-ha-dev] Re: [Linux-ha-cvs] riloe plugin commit

[Lars Marowsky-Bree]

On 2004-10-02T10:13:51,
   Lars Marowsky-Bree <lmb at suse.de> said:

> I've some concrete ideas on how to improve things while preserving the
> current C plugin module as the primary option and still address my
> issues with the current state. And will send a proof-of-concept patch by
> Sunday evening my time. Then we can talk again ;-)

I just noticed I wrote Sunday. That's obviously wrong ;-) No work on a
Sunday!

But, the ideas are as follows:

- Improve the external plugin and in particular it's interaction with
  the external scripts, so that it becomes dead easy to write full
  STONITH plugins in shell/python/whatever.

- Add /usr/lib{64}/stonith/plugins/stonith/external/ (while at it, I
  might cut out one redundant stonith out of that path ;-) and make it
  the default search path for the external plugin.

- Good candidates for conversion to the external API are riloe + ssh for
  the time being.
  
These two should succeed at providing the following functionality:

- Looking at ha.cf, the user won't notice much difference whether he's
  calling an external script or not; compare:
  stonith_host * ssh <options>
  stonith_host * external ssh <options>
  
- Still, we convey that those are 'external' and explain the difference
  quite clearly to the user; one of them forks (which may be fine for
  most if not all intents of purposes), and the other 'native' plugins
  are integrated and pre-loaded (which is still a notch better).

  (And thanks Alan for opening the bug to track improving the native
  plugins; I think we ought to make sure those plugins do meet those
  high standards.)

- Benefit: I assume the ssh "plugin" will shrink considerably going from
  C to shell. Less lines of code, same functionality. Always a good
  deal. Same for the riloe.py script; the gory details will be handled
  within the external plugin.

For some plugins (the apcmastersnmp, ipmi etc) it's I think quite clear
that a C plugin is a good way to go; they don't have to go and parse a
lot of text or call external programs. But, for example, the things
which actually go and parse text coming from a power switch would
probably be better of being written in Perl/Python.

Does that sound sane?


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

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company