Re: [Freeipmi-devel] setting thresholds

[Al Chu]

Hey Gregor,

On Fri, 2008-01-25 at 18:36 +0100, Gregor Dschung wrote:
> Hey Al,
> 
> I don't really get your fears. If I checkout something from the bmc /
> sensors, I expect the status-quo of the bmc/sensor-threshold-settings.
> If I don't know s.th. about a section / item, I don't touch it and so it
> won't be changed by a commit.

That's assuming the vendor implemented the commit correctly :-)

Reading your e-mail, I do admit that my fears may be due to a few
extremely bad experiences with some early beta-hardware from vendors.
In reality, perhaps the concern is not as big as my fears and I should
relax it a bit.

> When I get an item, which is commented out, I suppose it's a "read only
> setting", first. If you wanted to pretend the user, you could suppress
> the "dangerous" items by default and write them out only, when the user
> forces a verbose (-v) output.

This idea would be better than my comment out fields approach as I said
before.  Perhaps for a few areas that I feel are "uber-advanced", we
leave it to a --advanced or something kind of output.

> Why should the user be able to enable / disable sensors? If I don't want
> to use a specific sensor as a trigger for an event, I don't configure a
> corresponding event-filter-entry, or ? Is the enable / disable-feature
> in the specs, at all?

I had simply considered the possibility since it is an edittable field
according to the IPMI spec.  Most would not care .. but ... maybe some
would?

> For the checkout, I imagine s.th. like the following:
> 
> # Sensor Name: Temp
> Section Sensor_1              // -> Sensor_<unique sensor-id>). Not the
> sensor-name, 'cause different sensors can have the same name.
>        ## Give your thresholds. Possible values: float number. -
> disables the threshold
>        Lower_Critical         10.0
>        Upper_Critical         60.0
>        Lower_Noncritical      15.0
>        Upper_Noncritical      65.0
>        Upper_Nonrecoverable   -
>        Upper_Nonrecoverable   -
> EndSection
> # Sensor Name: Ambiant Temp
> Section Sensor_2
>        ## Give your thresholds. Possible values: float number. -
> disables the threshold
>        Lower_Critical         -
>        Upper_Critical         50.0
>        Lower_Noncritical      -
>        Upper_Noncritical      45.0
>        Upper_Nonrecoverable   -
>        Upper_Nonrecoverable   -
> EndSection
> [...]
> 
> I think, the sensors, which don't relate to the Event Type 1h
> (threshold-able sensors) don't have any setting, which is configurable
> by the user. So they don't need to be listed in the checkout.

The "set sensor event enable" command seems to allow you to
enable/disable individual events for individual discrete sensors, for
example "AC power loss" event for a power supply.  I was thinking the
tool could allow the ability to enable/disable this event.

It would have to be an advanced feature though.  This shouldn't be out
there by default I think.

Thanks,
Al

> But for now, have a nice week-end :)
> Gregor
> 
> Al Chu wrote:
> > On Fri, 2008-01-25 at 07:41 -0800, Albert Chu wrote:
> >> Hey Gregor,
> >>
> >>> Btw, to strengthen the case against the command line interface: There
> >>> are different event triggers / event classes. For example, the event
> >>> trigger 02h relates to the "discrete"-event class which describes one of
> >>> the events "Transition to Idle / Active / Busy". Or the event trigger
> >>> 03h. It's a "digital discrete"-event class and describes the events
> >>> "State Asserted / Deasserted".
> >> I'm glad you brought that up.  As I was looking through the spec, I was
> >> wondering how deep I wanted to support the configuration.  There are some
> >> "scary areas" in IPMI that I fear configuring b/c so many vendors
> >> implement IPMI poorly.  When a vendor configures usernames/passwords
> >> incorrectly, and bmc-config subsequently messes something up, well, its
> >> only a username and password issue.  in-band IPMI can still work.
> >>
> >> Potentially enabling/disabling sensor scanning may make things really bad
> >> on a system.  Sort of like my initial resisitance to add boot-parameter
> >> configuration to bmc-config.
> >>
> >> I'm thinking perhaps I will just leave these "scary areas" commented out
> >> in the config after you do a checkout.  That way, if you really know what
> >> you're doing, you are welcome to uncomment and commit away.  It's sort of
> >> like the SOL port field in the bmc-config.  That's a scary config that I
> >> don't want people to write to the BMC by default.
> >>
> >> What do you think?
> >
> > Thinking about this a bit more, I suppose it begs the question, why
> > don't I just leave all fields uncommented until the user wants to
> > configure them. 
> >
> > Maybe its enough to say that bmc-config is "generic", but sensors-config
> > is "advanced", so you better know what you're doing if you're going to
> > be using "sensors-config"???
> >
> > Al
> >
> >> Al
-- 
Albert Chu
address@hidden
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory