Re: [Freeipmi-devel] setting thresholds
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:[EMAIL PROTECTED]:/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_). 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 [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] setting thresholds
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_). 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
Re: [Freeipmi-devel] setting thresholds
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_). 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 ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] setting thresholds
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 > > > Hey, > > > > I would prefer the direct integration into 'ipmi-sensors'. A tool called > > 'ipmi-sensors-config' would be my second choise, if you prefer to let > > ipmi-sensors a read-only tool. > > > > 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". > > So in order to the many command line arguments which would be required > > by a command line implementation, the tool would be unclear. > > > > Regards, > > -Gregor > > > > Al Chu wrote: > >> As I look through the IPMI spec, I realize now that setting thresholds > >> has nothing to do w/ the SDR. It seems to be a configurable field > >> independent of the SDR. Event enabling/disabling of the sensor also > >> seems to be independent of the SDR. > >> > >> So perhaps, this should not be 'ipmi-sdr' or 'sdr-config' but rather > >> something else. "ipmi-sensor-config"?? Seems sort of long. Any better > >> ideas for a tool name? Or should we just add a --checkout/--commit/-- > >> diff into 'ipmi-sensors'? The later is an idea I don't like. > >> > >> Al > >> > >> On Mon, 2008-01-14 at 10:39 -0800, Al Chu wrote: > >> > >>> Hey Gregor, > >>> > >>> Cool. I've added it to the TODO. I don't have a timeline for 0.6.0 at > >>> the moment. When I have something more concrete, I'll give you a ping > >>> for some comments. > >>> > >>> Al > >>> > >>> On Mon, 2008-01-14 at 19:31 +0100, Gregor Dschung wrote: > >>> > Hey Al, > > nice news :) > > I would prefer a pef-config like interface. The feature to save the > whole > config in a file is THE argument to use FreeIPMI. > > Regards, > -Gregor > > > > Hey Gregor, > > > > At the moment there isn't a tool to do this. An 'ipmi-sdr' tool has > > been on the todo for years. I'm slating this tool to be in FreeIPMI > > 0.6.0. > > > > I haven't thought of an interface that would be suitable for > > threshold > > configuration. Would a pef-config/bmc-config like interface be best? > > Or a command line interface like: > > > > --set-upper-threshold=80 > > --set-lower-threshold=40 > > > > ?? > > > > Al > > > > On Fri, 2008-01-11 at 18:36 +0100, Gregor Dschung wrote: > > > >> Hi, > >> > >> I'm missing the option to set the thresholds of sensors. > >> > >> It would be nice to have a utility like pef-config or bmc-config, > >> which > >> allows me to write out the current configuration and to commit a > >> template file. > >> > >> Or have I overlooked something? > >> > >> Best regards, > >> Gregor > >> > >> > > -- > > Albert Chu > > [EMAIL PROTECTED] > > 925-422-5311 > > Computer Scientist > > High Performance Systems Division > > Lawrence Livermore National Laboratory >
Re: [Freeipmi-devel] setting thresholds
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? Al > Hey, > > I would prefer the direct integration into 'ipmi-sensors'. A tool called > 'ipmi-sensors-config' would be my second choise, if you prefer to let > ipmi-sensors a read-only tool. > > 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". > So in order to the many command line arguments which would be required > by a command line implementation, the tool would be unclear. > > Regards, > -Gregor > > Al Chu wrote: >> As I look through the IPMI spec, I realize now that setting thresholds >> has nothing to do w/ the SDR. It seems to be a configurable field >> independent of the SDR. Event enabling/disabling of the sensor also >> seems to be independent of the SDR. >> >> So perhaps, this should not be 'ipmi-sdr' or 'sdr-config' but rather >> something else. "ipmi-sensor-config"?? Seems sort of long. Any better >> ideas for a tool name? Or should we just add a --checkout/--commit/-- >> diff into 'ipmi-sensors'? The later is an idea I don't like. >> >> Al >> >> On Mon, 2008-01-14 at 10:39 -0800, Al Chu wrote: >> >>> Hey Gregor, >>> >>> Cool. I've added it to the TODO. I don't have a timeline for 0.6.0 at >>> the moment. When I have something more concrete, I'll give you a ping >>> for some comments. >>> >>> Al >>> >>> On Mon, 2008-01-14 at 19:31 +0100, Gregor Dschung wrote: >>> Hey Al, nice news :) I would prefer a pef-config like interface. The feature to save the whole config in a file is THE argument to use FreeIPMI. Regards, -Gregor > Hey Gregor, > > At the moment there isn't a tool to do this. An 'ipmi-sdr' tool has > been on the todo for years. I'm slating this tool to be in FreeIPMI > 0.6.0. > > I haven't thought of an interface that would be suitable for > threshold > configuration. Would a pef-config/bmc-config like interface be best? > Or a command line interface like: > > --set-upper-threshold=80 > --set-lower-threshold=40 > > ?? > > Al > > On Fri, 2008-01-11 at 18:36 +0100, Gregor Dschung wrote: > >> Hi, >> >> I'm missing the option to set the thresholds of sensors. >> >> It would be nice to have a utility like pef-config or bmc-config, >> which >> allows me to write out the current configuration and to commit a >> template file. >> >> Or have I overlooked something? >> >> Best regards, >> Gregor >> >> > -- > Albert Chu > [EMAIL PROTECTED] > 925-422-5311 > Computer Scientist > High Performance Systems Division > Lawrence Livermore National Laboratory > > > > > -- > Gregor Dschung > System Life Guard, HiWi > > Fraunhofer-Institut für Techno- > und Wirtschaftsmathematik ITWM > Fraunhofer-Platz 1 > D-67663 Kaiserslautern > > E-Mail: [EMAIL PROTECTED] > Internet: www.itwm.fraunhofer.de > -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] setting thresholds
Hey, I would prefer the direct integration into 'ipmi-sensors'. A tool called 'ipmi-sensors-config' would be my second choise, if you prefer to let ipmi-sensors a read-only tool. 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". So in order to the many command line arguments which would be required by a command line implementation, the tool would be unclear. Regards, -Gregor Al Chu wrote: > As I look through the IPMI spec, I realize now that setting thresholds > has nothing to do w/ the SDR. It seems to be a configurable field > independent of the SDR. Event enabling/disabling of the sensor also > seems to be independent of the SDR. > > So perhaps, this should not be 'ipmi-sdr' or 'sdr-config' but rather > something else. "ipmi-sensor-config"?? Seems sort of long. Any better > ideas for a tool name? Or should we just add a --checkout/--commit/-- > diff into 'ipmi-sensors'? The later is an idea I don't like. > > Al > > On Mon, 2008-01-14 at 10:39 -0800, Al Chu wrote: > >> Hey Gregor, >> >> Cool. I've added it to the TODO. I don't have a timeline for 0.6.0 at >> the moment. When I have something more concrete, I'll give you a ping >> for some comments. >> >> Al >> >> On Mon, 2008-01-14 at 19:31 +0100, Gregor Dschung wrote: >> >>> Hey Al, >>> >>> nice news :) >>> >>> I would prefer a pef-config like interface. The feature to save the whole >>> config in a file is THE argument to use FreeIPMI. >>> >>> Regards, >>> -Gregor >>> >>> Hey Gregor, At the moment there isn't a tool to do this. An 'ipmi-sdr' tool has been on the todo for years. I'm slating this tool to be in FreeIPMI 0.6.0. I haven't thought of an interface that would be suitable for threshold configuration. Would a pef-config/bmc-config like interface be best? Or a command line interface like: --set-upper-threshold=80 --set-lower-threshold=40 ?? Al On Fri, 2008-01-11 at 18:36 +0100, Gregor Dschung wrote: > Hi, > > I'm missing the option to set the thresholds of sensors. > > It would be nice to have a utility like pef-config or bmc-config, which > allows me to write out the current configuration and to commit a > template file. > > Or have I overlooked something? > > Best regards, > Gregor > > -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory -- Gregor Dschung System Life Guard, HiWi Fraunhofer-Institut für Techno- und Wirtschaftsmathematik ITWM Fraunhofer-Platz 1 D-67663 Kaiserslautern E-Mail: [EMAIL PROTECTED] Internet: www.itwm.fraunhofer.de ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] setting thresholds
As I look through the IPMI spec, I realize now that setting thresholds has nothing to do w/ the SDR. It seems to be a configurable field independent of the SDR. Event enabling/disabling of the sensor also seems to be independent of the SDR. So perhaps, this should not be 'ipmi-sdr' or 'sdr-config' but rather something else. "ipmi-sensor-config"?? Seems sort of long. Any better ideas for a tool name? Or should we just add a --checkout/--commit/-- diff into 'ipmi-sensors'? The later is an idea I don't like. Al On Mon, 2008-01-14 at 10:39 -0800, Al Chu wrote: > Hey Gregor, > > Cool. I've added it to the TODO. I don't have a timeline for 0.6.0 at > the moment. When I have something more concrete, I'll give you a ping > for some comments. > > Al > > On Mon, 2008-01-14 at 19:31 +0100, Gregor Dschung wrote: > > Hey Al, > > > > nice news :) > > > > I would prefer a pef-config like interface. The feature to save the whole > > config in a file is THE argument to use FreeIPMI. > > > > Regards, > > -Gregor > > > > > Hey Gregor, > > > > > > At the moment there isn't a tool to do this. An 'ipmi-sdr' tool has > > > been on the todo for years. I'm slating this tool to be in FreeIPMI > > > 0.6.0. > > > > > > I haven't thought of an interface that would be suitable for threshold > > > configuration. Would a pef-config/bmc-config like interface be best? > > > Or a command line interface like: > > > > > > --set-upper-threshold=80 > > > --set-lower-threshold=40 > > > > > > ?? > > > > > > Al > > > > > > On Fri, 2008-01-11 at 18:36 +0100, Gregor Dschung wrote: > > >> Hi, > > >> > > >> I'm missing the option to set the thresholds of sensors. > > >> > > >> It would be nice to have a utility like pef-config or bmc-config, which > > >> allows me to write out the current configuration and to commit a > > >> template file. > > >> > > >> Or have I overlooked something? > > >> > > >> Best regards, > > >> Gregor > > >> > > > -- > > > Albert Chu > > > [EMAIL PROTECTED] > > > 925-422-5311 > > > Computer Scientist > > > High Performance Systems Division > > > Lawrence Livermore National Laboratory > > > -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] setting thresholds
Hey Gregor, Cool. I've added it to the TODO. I don't have a timeline for 0.6.0 at the moment. When I have something more concrete, I'll give you a ping for some comments. Al On Mon, 2008-01-14 at 19:31 +0100, Gregor Dschung wrote: > Hey Al, > > nice news :) > > I would prefer a pef-config like interface. The feature to save the whole > config in a file is THE argument to use FreeIPMI. > > Regards, > -Gregor > > > Hey Gregor, > > > > At the moment there isn't a tool to do this. An 'ipmi-sdr' tool has > > been on the todo for years. I'm slating this tool to be in FreeIPMI > > 0.6.0. > > > > I haven't thought of an interface that would be suitable for threshold > > configuration. Would a pef-config/bmc-config like interface be best? > > Or a command line interface like: > > > > --set-upper-threshold=80 > > --set-lower-threshold=40 > > > > ?? > > > > Al > > > > On Fri, 2008-01-11 at 18:36 +0100, Gregor Dschung wrote: > >> Hi, > >> > >> I'm missing the option to set the thresholds of sensors. > >> > >> It would be nice to have a utility like pef-config or bmc-config, which > >> allows me to write out the current configuration and to commit a > >> template file. > >> > >> Or have I overlooked something? > >> > >> Best regards, > >> Gregor > >> > > -- > > Albert Chu > > [EMAIL PROTECTED] > > 925-422-5311 > > Computer Scientist > > High Performance Systems Division > > Lawrence Livermore National Laboratory > > -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] setting thresholds
Hey Al, nice news :) I would prefer a pef-config like interface. The feature to save the whole config in a file is THE argument to use FreeIPMI. Regards, -Gregor > Hey Gregor, > > At the moment there isn't a tool to do this. An 'ipmi-sdr' tool has > been on the todo for years. I'm slating this tool to be in FreeIPMI > 0.6.0. > > I haven't thought of an interface that would be suitable for threshold > configuration. Would a pef-config/bmc-config like interface be best? > Or a command line interface like: > > --set-upper-threshold=80 > --set-lower-threshold=40 > > ?? > > Al > > On Fri, 2008-01-11 at 18:36 +0100, Gregor Dschung wrote: >> Hi, >> >> I'm missing the option to set the thresholds of sensors. >> >> It would be nice to have a utility like pef-config or bmc-config, which >> allows me to write out the current configuration and to commit a >> template file. >> >> Or have I overlooked something? >> >> Best regards, >> Gregor >> > -- > Albert Chu > [EMAIL PROTECTED] > 925-422-5311 > Computer Scientist > High Performance Systems Division > Lawrence Livermore National Laboratory > ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
Re: [Freeipmi-devel] setting thresholds
Hey Gregor, At the moment there isn't a tool to do this. An 'ipmi-sdr' tool has been on the todo for years. I'm slating this tool to be in FreeIPMI 0.6.0. I haven't thought of an interface that would be suitable for threshold configuration. Would a pef-config/bmc-config like interface be best? Or a command line interface like: --set-upper-threshold=80 --set-lower-threshold=40 ?? Al On Fri, 2008-01-11 at 18:36 +0100, Gregor Dschung wrote: > Hi, > > I'm missing the option to set the thresholds of sensors. > > It would be nice to have a utility like pef-config or bmc-config, which > allows me to write out the current configuration and to commit a > template file. > > Or have I overlooked something? > > Best regards, > Gregor > -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory ___ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel
