[rrd-developers] [RRDCacheD] Developing RRDCacheD as separate project (was: Authentication)
Thorsten von Eicken
tve at voneicken.com
Sat Apr 11 01:48:20 CEST 2009
Well, if you open the discussion... I'd love to see the following:
- RRDTool sans rrdgraph at the bottom layer for managing the data storage
- An HTTP/REST style service that provides remote access to the data
store using semantics that are relatively independent of the rrd details
(at least for store/fetch requests, create can have a pile of specific
args, for example)
- An RRD graph library that has a pluggable back-end to fetch the data
into which one can easily plug various storage systems, such as local
RRD store, remote RRD store, or a different store altogether.
I believe the current RRDTool is not that far from the above
architecture, but it's not there. Having an HTTP based service on top of
the data layer would allow for a lot of flexibility. Like it or not,
HTTP has become the standard plumbing, at least in my world. Think of
passing the requests through a load balancer to spread the storage
across multiple store servers. Or using HTTPS for security. I believe in
the end the real bottleneck will remain at the disk level and the HTTP
overhead can be accommodated.
Having the graphing be more decoupled from the storage is something that
has been requested many times over, I believe.
Florian Forster wrote:
> Hi Tobi, Thorsten, Kevin, and list,
> sorry I took my time to answer – I wanted to sleep on this first and
> don't make any premature decisions.
> On Thu, Apr 09, 2009 at 04:31:02PM +0200, Tobias Oetiker wrote:
>> I love the rrdcached functionality and all the work you did on it and
>> I would not want to miss it.
>> But it also makes me sad to see you angry or unhappy. So if you feel
>> that it is better for you to run your own show, I am perfectly ok with
>> you doing a fork of the cache daemon and hooking it up to librrd. This
>> will give you the freedom to develop it in any direction you feel is
> Yes, I think separating the development would make sense and ultimately
> the open-source community will benefit from it. The bonding between the
> daemon and RRDtool would be lessened, but that isn't necessarily a bad
> thing in my opinion. RRDtool wouldn't have yet another binary interface
> to worry about and new releases of either project could be made whenever
> appropriate and independently from one another.
> I'd like to act upon a consensus here, though. “Forking” the daemon,
> i. e. leaving the daemon in RRDtool and developing a second one, is out
> of question for me: This would create a diversity nobody would benefit
> It'd be nice to hear some more opinions on the matter, especially which
> development model Kevin would prefer and whether or not he'd volunteer
> to maintain a separate project?
> On Thu, Apr 09, 2009 at 07:52:21AM -0700, Thorsten von Eicken wrote:
>> Guys, I fear this is descending into a non productive direction. Why
>> don't the two of you just pick up an old-fashioned phone or link up
>> via IRC or whatnot and just "talk it out". I'm sure you can resolve
>> this disagreement in a nice manner that allows us to continue enjoying
>> the good collaboration between collectd and rrdtool. Cheers!
> Actually, I think the discussion is productive and I'm sure we will come
> to a conclusion everybody can agree with. I'm sorry if my more heated
> statements made this debate feel like a conflict and would like to
> apologize for the form – I stand by my arguments, however.
More information about the rrd-developers