Hi. This week I had an exam (last one) and I had to spend ~2.5 days on it. Zack was notified in advance.
By points of last week: > Next week will be spent to: > 1. Catch up (because of some failed attemps to adapt the scripts a lot of > time was lost) and finish usecases investingation. More scripts will be > adapted for use by debmetrics. Done. Result: most graphs of the "simple" metrics can be represented as trends with "date" on X axis and numerical values on Y axis. A new type (remote-pull) of remote metric was added. > 2. Design the database scheme to store the data After an intense discussion and research we decided that we shall use rrdtool, it does exactly what we want to. Another reason not to use SQL databases is difficulties in maintainance and performance issues. rrdtool also satisfies usecases of simple metrics. Some time was spent on reading docs, learning basics of rrdtool and research on Python APIs. I've coded adding new metric (with creating related rrd database, but it requires some improvement and changes to manifest files) > 3. A script for updating the graphs that will run periodically. Done as 2 scripts - one to add entries to user's crontab and another to execute udpated. Results are saved into rrd db. Next week (Sat-Sun): Fix the issue with creating rrd dbs (mentioned above in point 2). Fix bugs in current data update code. Next week (Mon-Fri): 1. Code the setup script and other maintainence scipts. As a result adding new metrics would be as easy as "drop the script and run ``make''". 2. Start coding a web interface for metrics output. An expected result: retrieving data from rrd databases and printing it out. Possibly, retrieving data by different time interval. Possibly, remote-push data processing. Regarding the schedule issue mentioned last week. It appears that most of the job that I planned for last weeks is being done now. It's good, because I didn't plan to look at usecases by the time of writing that schedule, but as I see now, it is required. Now, because I have a full picture of what are the usecases and how scripts should be ported, I think that "August 26 - September 1" and "September 2 - 23" points can be reduced. -- С наилучшими пожеланиями, Boris
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Soc-coordination mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/soc-coordination
