freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freeipmi-devel] sun20 workaround doesn't


From: Al Chu
Subject: Re: [Freeipmi-devel] sun20 workaround doesn't
Date: Wed, 10 Jun 2009 10:27:47 -0700

Hey Dave,

On Wed, 2009-06-10 at 15:31 +0100, Dave Love wrote:
> Al Chu <address@hidden> writes:
> 
> > Hehe.  It's funny you mention this.  I had a request/comment on this
> > topic just last week.  First, please take a look at my original post on
> > this for what I was thinking of supporting:
> >
> > http://www.mail-archive.com/address@hidden/msg00710.html
> 
> For what it's worth, although that suggests you don't want sensor data
> from heterogeneous hosts, but that's one of my application.
> Specifically for out-of-band temperature data fed to ganglia, the ELOM,
> ILOM, and Supermicro values can be translated to consistent names,
> though I'm not currently doing that.

Ahhhh.  I take it you are using the hostrange feature as a "go get data
faster" mechanism.  I suppose I was thinking more about the
buffer/consolidate options (-B, -C).  Using them against a heterogenous
environment didn't make too much sense to me.

> > The work involved is somewhat deep
> 
> Just as well I asked, then, before trying to dive in!  I could probably
> help out, given instructions for part of the job, if it will partition.

Thanks for the offer, but I think this is something I'll have to suffer,
b/c it will take a fair amount of re-architecture, which I admit I still
don't know how I'm going to do :-)

> > (that I've naturally been putting
> > off, but it is now higher priority b/c it came as a request from someone
> > internal to my organization).  As far as I can tell, it would take:
> >
> > A) re-work a lot of the config file parsing code to be able to take an
> > additional argument.  Based on other people's requests, this would be
> > for all the config file options.  It could be made easier if instead of
> > modifying all config file options to take the additional argument, we
> > made new config file options, like:
> 
> I'd initially have thought of trying to have host-specific sections in
> the file, e.g. with the common `[<header name>]' style, but I doubt it
> matters from a user point of view, so it would be a question of what's
> easiest to program.

ohhh, you mean like:

Section nodes[0-11]
  workarounds sun20
End
Section nodes[0-12]
  workarounds intel20
End

That's an idea too.  The config-file parsing lib I have doesn't support
that (yet), which is why I didn't really consider it.  Hmmmm.

Al

-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory





reply via email to

[Prev in Thread] Current Thread [Next in Thread]