[Linux-ha-dev] new stonith external plugin

[Andrew Beekhof]

On 1/29/07, Dave Blaschke <debltc at us.ibm.com> wrote:
> Andrew Beekhof wrote:
> > On 1/29/07, Serge Dubrouski <sergeyfd at gmail.com> wrote:
> >> On 1/29/07, Lars Marowsky-Bree <lmb at suse.de> wrote:
> >> > On 2007-01-29T10:10:44, Andrew Beekhof <beekhof at gmail.com> wrote:
> >> >
> >> > > >Attached is an update version. It supports on and off commands now.
> >> > > >User still have to configure hostlist in a form "node:xen0_host
> >> > > >node:xen0_host ...".
> >> > > thats going to be a pain when the VMs are also resources (and
> >> therefor
> >> > > moving around).
> >> > >
> >> > > or aren't we dealing with this case here?  i loose track
> >> sometimes :-)
> >> >
> >> > That's not being dealt with, AFAIK. In that case, the command wouldn't
> >> > be a xm shutdown/start, but a "crm_resource ..." invocation;
> >> potentially
> >> > one trying to stop a specific clone. I'm not sure _you_ want to deal
> >> > with that yet. ;-)
> >> >
> >> > However, I think it could be simplified.
> >> >
> >> > First, in many cases, all the virtual guests are going to be on a
> >> single
> >> > physical node. (ie, test "clusters".) Then only supplying one node to
> >> > ssh to should be sufficient.
> >>
> >> Let's nod discuss trivial cases.
> >>
> >> >
> >> > Second, by providing a simple list of all physical nodes, the system
> >> > should be able to automatically figure out which node it needs to
> >> ssh to
> >> > to shot the guest. It could try to autopopulate the hostlist from
> >> > /etc/xen/vm/* or some other directory, as well.
> >>
> >> Ok, Let's say user provided us with 3 Xen0 Nodes and ALL 3 of them
> >> have config file for node1 in /etc/xen/vm. Then where should I start
> >> node1 when "on" command is called?
> > wouldn't you just use the same node name that you used for "off"?
> >
> > or are "on" and "off" distinct operations sent to you from the stonithd?
> >
> > by that i mean that stonithd will never just tell you to turn a node
> > on, only to stop or reset it in some way.  so if you were able to do
> > the "off", then you know you can also do the "on".
> Sorry to interrupt the flow of this thread, but I have been off chasing
> down other non-HA problems...
>
> Yes, "on" and "off" are distinct operations sent from stonithd.
> However, in the event of a STONITH condition, I believe that only
> "reset" is sent by stonithd (hence why "on" and "off" are optional
> parameters, while "reset" is required).  Indeed, even some STONITH
> plugins do not recognize the "on" and "off" parameters.  The "on" and
> "off" parameters were added to the stonith command so that one could
> reset and power on/off nodes from the command line, so it is possible
> for a plugin to receive the "on" or "off" command but that would
> indicate that the request came from outside stonithd (command line,

which means that we can assume that the RA will only ever receive an
"off" or a "reset" (since we'll never ask for a node to be powered
on).

in this context, that would mean we only ever need to do a "xm
destroy" or a "xm reboot" (neither of which require a path to a vm
config file) and should help simplify the RA.

> script).  I am not able to grep through the code right now (my pSeries
> machine is no longer accepting connections to HMCs so it is lost in
> space) to verify my statements, but I believe them to be true from my
> journeys through STONITH code...
> >
> >>
> >> >
> >> > Then having to actually configure something should be quite rare.
> >> >
> >> > (Note that dealing with dead physical nodes is slightly tricky.)
> >> >
> >> > > as an aside (for lars/alan), would it be worthwhile having these
> >> > > plugins use the OCF RA standard instead?
> >> >
> >> > They already mostly are.
> >> >
> >> >
> >> > Sincerely,
> >> >    Lars
> >> >
> >> > --
> >> > SUSE Labs, Research and Development
> >> > SUSE LINUX Products GmbH - A Novell Business     -- Charles Darwin
> >> > "Ignorance more frequently begets confidence than does knowledge."
> >> >
> >> > _______________________________________________________
> >> > Linux-HA-Dev: Linux-HA-Dev at 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 at 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 at 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 at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
>