[rrd-developers] Add `FETCH' command to rrdcached

[Tobias Oetiker]

Today Florian Forster wrote:

> Hi Tobi,
>
> On Mon, Apr 06, 2009 at 05:11:25PM +0200, Tobias Oetiker wrote:
> > I would want to schedule this for 1.5 though and not rush it into 1.4
>
> I'd prefer to see this in 1.4, since I hope that the possibility to
> create graphs without physical access to the RRD files will be welcome
> by many. The changes to ?rrd_daemon.c? and ?rrd_client.[ch]? are not
> exactly nice, but simple, so the number of new bugs in that code is
> hopefully low.
>
> I have to admit I wasn't away that version 1.4 was due soon. Is there
> information available regarding the release plans?

the 'release plan' is 'beta in april', 'release in mai'

if you are up for polishing the graph integration and we get the
auth going, I am all for integrating it in 1.4.
>
> > a) looking at the patch I see that the flushing operation is
> >    included in rrd_graph (this is not new).
>
> It is? I can't find it:
> -- 8< --
>  octo at leeloo:~/rrdtool-trunk.git $ git branch | fgrep '*'
>  * ff/rrdc_fetch
>  octo at leeloo:~/rrdtool-trunk.git $ grep -i flush src/rrd_graph.c || echo "No match"
>  No match
> -- >8 --
>
> Anyways, the changes made to ?rrd_{fetch,graph}.c? were meant for
> discussion only, and I think we've reached the consensus that including
> a daemon address on a per-file level is preferable to the existing code.

well it is in the official repo ... dont know about the git mirror
though ...

                if (status == 0)
                {
                    status = rrdc_flush (im->gdes[i].rrd);
                    if (status != 0)
                    {
                        rrd_set_error ("rrdc_flush (%s) failed with status %i.",
                                im->gdes[i].rrd, status);
                        return (-1);
                    }
                }

>
> >    - when called with normal filenames, the code would acct
> >      accoring to the environment variable settings or the --daemon
> >      setting.
> >
> >    - alternatively rrd_graph (rrd_fetch) should support a extended
> >      filename syntax: port at server/rrd_path (I am not using :port
> >      since : is already a separator in the rrd_graph syntax
>
> I propose a slightly different approach:
>
>  - ?rrdtool fetch? behaves as implemented in my third patch, i. e. if a
>    daemon address is known, it will send a ?FETCH? command instead of a
>    ?FLUSH? command.
>
>  - The ?DEF:? syntax is extended to recognize the ?address? (or ?daddr?
>    for ?daemon address?) and ?port? (or ?dport?) options, for example:
>
>      DEF:foobar=/path/to/file:AVERAGE:address=my.server.tld:port=12345
>
>    I think this is less magicy than adding special syntax to the
>    filename and therefore easier to comprehend.

the syntax is fine by me ...

>    Also, this keeps magic
>    out of `rrd_fetch' and keeps the distinction clear and easy:
>
>     * ?rrd_fetch? and ?rrd_fetch_r? are for local file access.
>     * ?rrdc_fetch? is for remote file access.

hmmm the 'problem' is that through this only graph will benefit and
fetch will not, causing all code that uses both fetch and graph to
not be able to use the remote data access ...

in smokeping for example I am using a call to fetch to calculate
some data I am including in the graph by using a 'magic' filename
the code could be very easily enhanced to work with remote files,
using named arguments it becomes more complex, either we leave
rrd_fetch completely out or we provide a new function call with
additional arguments ...

> > finally, I am planning to add shared secret based authentication to
> > 1.5 so that one can use the cached over the network even when the
> > network is not inside a firewalled cluser.
>
> Sounds good :)

cheers
tobi

>
> Regards,
> -octo
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900