[rrd-developers] RRDCacheD - Client rewriting path

[Tobias Oetiker]

Hi Sebastian,

Saturday Sebastian Harl wrote:

> Well, I'd try to keep behavior consistent when talking to the daemon,
> i.e. something along the lines of the new file-name syntax proposed
> earlier (by Florian iIrc). In short: specify that you're talking to the
> daemon and then use relative path names (relative to the daemon's base
> directory).

the whole pathname encoding as it is already present with the dbi
patch is the way I would like to go ... but not in 1.4 since there
are other issues with the call interface that I would like to
address at the same time ... named versus positional arguments in
rrdgraph for example ...

> *Personally*, I'm not sure about the benefits of being able to
> transparently hide the daemon in a local setup (i.e. keeping a
> consistent behavior in regard to file names when talking to the daemon
> or accessing the files directly). The reasons for that are two-fold:
>
>  a) RRDCacheD is (mostly) for large setups which (imho) will not benefit
>     from that transparency. So the benefits would be limited to a small
>     number of users only, while (again imho) bringing along some
>     negative aspects as well (see, e.g., (b)).
>
>  b) Introducing that transparency probably will encourage mixing direct
>     and "cached" access to RRD files. This is error prone (e.g. cached
>     updates will basically be lost after a direct access using a later
>     time stamp), which is especially bad when it happens accidentally
>     (which, in turn, is not unlikely given the many, transparent ways to
>     use or skip the daemon; e.g. think about the environment variables,
>     etc.). I could perfectly understand any user who's seriously annoyed
>     by that.

people will be annoyed in any case ... in the end it comes down
which annoyances I can more easily face ... and annoyances of
people who break their system because they did not follow the
instructions, for me are more easily to bear than annoyances of
people who grief because we did not provide them with a perfectly
simple path to fit RRDCacheD into their existing monitoring
infrastructure, especially into old and complex ones, without
introducing additional burdens like the necessity of supporting a
new path name scheme (or two since at the moment not all rrdtool
communications can go through the daemon)

> Then again, I'm thinking of RRDCacheD as a network daemon and, thus, it
> should imho be optimized for that. It might not be perfect yet, but it's
> already very well suited for that purpose and I'm pretty sure that's
> where we're going to.

yes ... I agree there is lots of potential ... but then again we
are not realy talking about changes to the daemon. Only about the
client side ...

> There's a lot of "imho" in the above text, so it'd be nice to hear some
> other voices on that topic but from previous discussions I got the
> impressions that there are other people thinking similar to me.

well I waited a bit with my reply but it seems this discusssion
seems to hold little interest for others ... it's just us it seems.

> I hope this could clarify my point of view.
>
> > > > but then again, remote use of rrdcached will see some further changes
> > > > with authentication and authorization anyway ...
> > >
> > > Yes, but (as far as I see it) that should be possible without breaking
> > > backward-compatibility (since the fine-grained permission handling has
> > > been included).
> >
> > not breaking backward compatibility or at least continuing to
> > provideing the old interface as well is always a concern for me ...
>
> Yes, I know :-) That's why I insist so hard on getting this straight
> before 1.4.

I see the introduction of 'URL' support as a task for 1.5. Done in a
way to work accross the board, so that all parts of  rrdtool can
profit from this ... graphs with data from different daemons and
such ...

I still think it would make a lot of sense to have rrd_update
complain when called in 'remote rrdcached' mode, without an absolute
path name ... turning the local path name into an absolute one
makes little sense for the remote case.

cheers
tobi





-- 
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