Re: [Freeipmi-devel] setting thresholds

[Gregor Dschung]

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