[Buildbot-devel] GSoC: Initial thoughts on the Graphs and Data Charts Project

[Prasoon Shukla]

*Disclaimer*: This post has no new data - just a clarification of the
discussion that has happened till now.

I think that we're not all thinking on the same page and that's leading to
confusions (as Dustin pointed out) so here's a sort of a quick
disambiguation post.

The first is the metrics module (I will refer to it as the
inbuilt-metrics-module from here on out to remove any confusion) - it
cannot be used outside of buildbot. I wrote as much in my last reply and
Dustin said it as well. It can only be used to gather data inside buildbot.

It was my impression that I was supposed to use this module
(inbuilt-metrics-module) to gather data for graphing. Of course, since the
module could not be used outside buildbot, it wasn't really much use in
gathering data except being called indirectly to just store data in the db.
This was also something I mentioned in my last mail.

Thinking that I had to use the inbuilt-metrics-module, I came up with the
problem of storage and retrieval *for the inbuilt-metrics-module *(not for
gathered statistics in general). So I proposed a solution for the storage
of data* for this inbuilt-metrics-module* which was simply this: Use the
same db as buildbot, create one table for each MetricEvent (as defined in
the inbuilt-metrics-module), store data as key value pair with a timestamp.

Now, I considered the problem of actually gathering (not storing) build
data from test suite. For clarity, let us call this measurable data as
test-statistic.

To use existing buildbot data gathering to the fullest, I divided the set
of all test-statistics into two kinds - time test-statistics and non-time
test-statistics. Then I said that we can use Steps to gather time statistic
as buildbot already times all Steps. For non-time test-statistics, I
suggested a script based approach where the user would do the gathering of
the test-statistics and then pass it on to buildbot for storage (and
subsequent graphing).

Then, I considered the storage of the test-statistics - not the
inbuilt-metrics-data but the test-statistics themselves.

For the time based test-statistics, buildbot is already doing the storage
for us.
For the non-time based test-statistics, we can use the
inbuilt-metrics-module to do the storage for us. Again, this would mean a
timestamped key-value pair.

As it turns out, this would suit our needs just fine since we can query the
database, extract the test-statistics in a given time range and graph them.

So, you can see why I considered this a feasible model.
Anyway, I'll reply to Mikhail's and Dustin's questions in the my next post.
ᐧ

On Tue, Mar 17, 2015 at 1:04 AM, Mikhail Sobolev <mss at mawhrin.net> wrote:

> On Mon, Mar 16, 2015 at 08:41:50PM +0200, Mikhail Sobolev wrote:
> > Hi Prasoon,
> >
> > On Mon, Mar 16, 2015 at 07:00:25PM +0530, Prasoon Shukla wrote:
> > > On Mon, Mar 16, 2015 at 12:31 PM, Mikhail Sobolev <mss at mawhrin.net>
> wrote:
> > >      Meanwhile you could present your ideas in more details.
> > >
> > >    Of course.
> > [snip]
> >
> > I'm sorry for not updating the project idea promptly, however I wanted
> to see
> > if somebody would suggest what I've been pondering for a while (maybe
> not that
> > nice of me).
> >
> > If one searches for the word 'metric', one could easily find a rather
> huge
> > number of products and projects dedicated to the topic.  There are two
> rather
> > big parts in there:
> >
> > * storage of metrics
> > * visualisation of metrics
> >
> > Each part, as I said, is big by itself.  I am afraid that if a GSoC
> project
> > would include both of them, it will not deliver anything more or less
> complete
> > in the allocated time.
> >
> > As we aim to have projects that can delivery something complete and
> useful, I'd
> > see the scope of "Graphs and Data Charts Projecet" to include:
> >
> > * identify what kind of metric "entities" need to be ipmlemented beside
> those
> >   that already exist and implement them
> > * implement a way to store metrics in an external metrics storage (my
> >   inclination would be InfluxDB)
> > * identify what kind of metrics we'd like to produce (entities (e.g.
> builds),
> >   parts of them (e.g. steps), etc); propose a naming scheme and list of
> >   "missing" functionality for metric generation (if any)
> > * implement metric generation in the agreed order (this will be agreed
> after
> >   the list in the previous step is produced)
> > * use an existing metric visualisation tool to see metrics for a test
> >   installation
> > * deploy the whole thing for nine.buildbot.net
> Please note that I created a ticket[1] with this items in and updated the
> tickets to make it a GSoC project while other ticket to just contribute to
> the
> content of the whole project.
>
> --
> Misha
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Buildbot-devel mailing list
> Buildbot-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/buildbot-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buildbot.net/pipermail/devel/attachments/20150317/8a60da49/attachment.html>