Re: [Freeipmi-devel] setting thresholds

[Albert Chu]

Hey Gregor,

I've finally committed a first attempt at the sensors config tool.  I've
settled on putting it into a new tool called "ipmi-sensors-config" for the
tool.  It currently only supports configuration of thresholds and none of
the sensor enabling/disabling.  I'm going to pass on that until the time
it is needed/requested.

Do you think you could take a look and LMK what you think of it?  It's
currently in the CVS head.

cvs -z3 -d:pserver:address@hidden:/sources/freeipmi co
freeipmi
cd freeipmi
./autogen.sh
./configure --enable-debug --enable-trace
(--enable-debug and --enable-trace if there are issues on your system)
cd ipmi-sensors-config/src

The manpage is in

ipmi-sensors-config/ipmi-sensors-config.8

I will intentionally leave out details, so we can see what you think w/o
me swaying your initial opinion :-)

Al

> 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.
> 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.
>
> 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?
>
> 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.
>
> 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