[Soc-coordination] [debmetrics] Week 2

[Boris Bobrov]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20130629/680d9a11/attachment.sig>