On Wed, 1 Nov 2006, Peter Bojanic wrote:
Jim,
On 2006-10-27, at 6:04 , Jim Garlick wrote:
OK, good to know!
There is a move afoot here to insert a database between lmtcollect
and xwatch-lustre and to add the ability to roll back time and plot
graphs just as you suggest. We're currently gathering requirements
for this effort, so now is a good time to request features.
Jim
Would Livermore consider gathering requirements from the Lustre community and
shifting your development efforts to the SourceForge site? It seems there is
much interest, and you may even benefit from community contribution.
Peter
Hi Peter,
The short answer is yes.
The long answer is we let the lmt SF site atrophy (sorry about that), but
based on comments here, we've fixed the one bug that's been reported,
added some internal maintenance changes, and have lmt-1.20 ready to push
up to SF (any day now). We will endeavor to keep SF alive as long as
there are people interested in the software. If there is demand (in the
form of lively discussion, patches, etc), we would be OK with switching
to more of a distributed development model, using SF mailman lists,
trackers, public svn, etc..
Internally, we're talking about lmt-2.0 and would like to take any community
comments into account as we plan it. So far we've heard agreement that
history + graphs are good and lustre-1.6 support is needed. If there are
other desirable features, we like to hear about them.
So far our discussions have lmtcollect feeding each sample to mysql, and
the client connecting to db's (one per file system) using the mysql API.
Initially the GUI would look like xwatch-lustre, but eventually we would
provide the ability to show historical views, plot individual values
(like I/O rates) over time, generate reports, etc.. We want to design
the system so the schema can change (new rows, etc) and the GUI will
automatically reflect those changes. We are thinking about an events
table where asynchronous events like LBUG's, crashes, etc could be
logged and then correlated with the performance and health data.
We think we will probably store the lustre cluster configuration in the
database statically rather than have it read XML as we do now or query
the MGS as it would need to do in lustre-1.6.
That's the current state of our thinking. The plan going forward is
to produce an informal design document before we start the work. I will
try to get that posted here for comment when we have it. Meanwhile,
please send on any thoughts!
Jim
_______________________________________________
Lustre-discuss mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
