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

List:       linux-ha-dev
Subject:    Re: [Linux-ha-dev] A Stonith API
From:       Alan Robertson <alanr () suse ! com>
Date:       2000-06-29 3:36:50
[Download RAW message or body]

David Brower wrote:
> 
> > > > This probably isn't a huge deal, and, as you said, it's easy to add.  If
> > > > you add it, then you also probably need to add a host_status() call also
> > > > which would tell you whether it's currently powered up or not.  My
> > > > particular device (the BayTech RPC5) has independent power inputs for
> > > > each machine, so it can also tell you if the power input for any
> > > > particular machine are live or not.  The switch itself is operational as
> > > > long as any one of the power inputs is live.  Curiously enough a given
> > > > machine can be powered on, yet have no power.  For this device, I could
> > > > imagine wanting an input_status() API call...
> > > >
> > > > So, there's a whole world of things which one could add to the API.
> > > >
> > > > Should we add an S_UNSUPPORTED return code for unimplemented opcodes?
> > >
> > > Opinions Galore:
> > >
> > > I think exposing host status is a Bad Idea.  That is what the monitoring
> > > code is supposed to be doing.
> >
> > But, there's no way to tell if power is off or on without it.  It is am
> > important complement to power on and off.  You don't want one without
> > the other.
> 
> Yes, there is:  the call returned that it completed successfully.
> It works, or it doesn't.

But, someone can come in manually and tell the device to shut off
power.  You don't in general know the state of power in the presence of
all the factors present (like human beings, software bugs, gremlins,
etc.)

> That doesn't mean you need a -separate- api on which to toss
> all sorts of status info that might be interesting in some cases.
> 
> I guess there are two things going on: (1) operational actions that
> actually do something.  And (2) status operations, which IMO belong
> in a management framework, not in the operational API.  You don't
> have details of your NIC in the socket APIs.  They show up in /proc
> and/or SNMP stuff, where the device specific stuff belongs.

OK.  I'm not sure I want to invent another API to do something whose
code is 90% common with the other API.  Maybe documenting the options as
being of a different class, and stating specifically that only
monitoring calls are optional?  Or, maybe even have a s_ops vector, and
an s_status vector, and if you implement one of them, you implement all
the operations, or none?

> > > I think UNSUPPORTED operations are a Bad Thing, because there is
> > > a tremendous temptation to code to the LCD, not the full set.
> > > What operations are required, and which optional?  It's madness
> > > to go that way.
> >
> > I can appreciate this.  It depends on what your goal is:
> >
> >         Restricting your options to the LCD (which is what not adding
> >                 other options would do), and not providing useful information
> >                 which doesn't make sense in some configurations.
> >         Restricting your hardware to the GCD.
> 
> I can't think of any operations proposed that I'd want
> to allow to be UNSUPPORTED, once you strip out monitoring.
> We have to have fence/reset -- it can't be UNSUPPORTED, or
> you don't have anything.

I don't think we *need* power off.  So, it *could* be optional.  This is
why I didn't include it in the first place.  Some types of STONITH
hardware can't support it.  I'm certainly OK with a minimal view of how
this should work.

I suppose hardware that pressed the reset button could simply do that
when asked to shut the machine off.  Or, would it be better to not put
in support for power off, or would it be better to say power off is
mandantory if the hardware supports it, but optional if it doesn't?  Or
is it just mandantory - period - don't use hardware that doesn't support
it?

	-- Alan Robertson
	   alanr@suse.com

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.tummy.com
http://lists.tummy.com/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

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