[rrd-developers] [PATCH] rrd_open and rrdcached

[Daniel Pocock]

Tobias Oetiker wrote:
> Today kevin brintnall wrote:
>
>   
>> On Wed, Oct 22, 2008 at 11:37:25AM +0100, Daniel.Pocock at barclayscapital.com wrote:
>>     
>>> rrdcached makes some calls to access and stat, which don't work for my
>>> virtual filesystem abstraction.
>>>
>>> This patch:
>>>       
>> Daniel,
>>
>> I am OK with this idea, but there are a few implementation details that
>> need fixing.
>>
>> Should the functions really be marked as RRD_DEPRECATED in "rrd.h"?  The
>> same question applies to other functions you introduced in that section of
>> the header (i.e. rrd_notify_row).
>>     
I'm not sure about that - I saw the comments in there about an API 
change, so I thought I should be consistent.  I'm hoping that this stuff 
is generic enough that it can be carried over to the new API and file 
format.
>> rrd_daemon.c must #include "rrd_tool.h" instead of "rrd.h"..  Otherwise,
>> it won't get the rrd_{access,stat} prototypes from the internal-only
>> section of rrd.h.
>>
>> In bindings/perl-shared, need to add "-std=c99" to the build args in order
>> to use "restrict" keyword in the rrd_{access,stat} prototypes...  Or, we
>> can remove "restrict" from the prototypes (I'm not sure how portable
>> "restrict" is).
>>     
>
> using c99 in rrdtool is fine, the public headers should not use
> c99isms though, since the world is not only gcc ...
>
>   
I copied that from the man page - but it may not be necessary

I was aiming to make it as much like the C library as possible, so that 
it will be easier for existing applications to be adapted.

>>> I'm also coming up against similar issues with Ganglia - gmetad wants to
>>> know if the RRD files already exist on disk, even though they only exist
>>> in my virtual back-end.  To deal with that, I'm thinking of adding some
>>> methods to the RRD API so that applications can do things like browsing
>>> the directory of RRDs.
>>>       
>> We'll have to find a way of doing it without pushing any changes into the
>> application (i.e. Ganglia) ...  There are zillions of custom RRD
>> applications out there that expect a file to exist.  We can't expect them
>> to adapt.
>>     
I'm not sure every application will need this level of scalability 
(although some people might like the flexibility of using SQL).

I don't think it's a bad thing if the applications have to be changed to 
take advantage of a new feature - nothing that I've done so far will 
break backwards compatibility or stop people using regular flat files.
>> A place-holder file makes sense... possibly empty, or possibly with enough
>> information to locate it in the striped file.
>>     
>
> there was this idea to have 'placeholder' files which would even
> allow todo fancy things like having rrdtool store data in an sql
> database for those who are so inclined.
>
>   
That is how I've hacked it to work in my lab, rrdcached and gmetad don't 
even know the difference.  My virtual filesystem creates the placeholder 
files on the fly.  However, that is 30,000 files with size 0, and it 
could cause confusion for someone not familiar with the reason for it.