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 [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list Freeipmifirstname.lastname@example.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel