[Gluster-devel] HTIME API
avishwan at redhat.com
Fri Oct 31 06:58:05 UTC 2014
Since HTIME file is available we need not maintain changelogs in two
different places as we do now(backend and working dir), We can provide
backend changelog names to consumer instead of working dir names. One
problem with this is for parsing these changelogs they have to use one
more RPC call. How about returning FOP details directly instead of
changelog file names?
If we use db(sqlite) internally in API itself then we can do multiple
1. If multiple data operations in requested time for a file then return
2. If a file/gfid is created and deleted in the requested time range
then skip from the output.
3. If a file/gfid is deleted in the given time then do not return data fops.
Other challenge is getting cluster view of these notifications.(and
On 10/31/2014 11:10 AM, Kotresh Hiremath Ravishankar wrote:
> Hi Venky,
> If I understand correctly, the idea is to provide RPC based history API?
> If yes, how can that solve the different clients/consumers having to maintain
> state of how much it has processed?
> Thanks and Regards,
> Kotresh H R
> ----- Original Message -----
> From: "Venky Shankar" <vshankar at redhat.com>
> To: "Ajeet Jha" <ajha at redhat.com>
> Cc: "Kotresh Hiremath Ravishankar" <khiremat at redhat.com>, gluster-devel at gluster.org
> Sent: Wednesday, October 29, 2014 6:23:40 PM
> Subject: HTIME API
> Hey Ajeet,
> Since changelog translator maintains a meta file (HTIME) containing a list of consumable changelogs, we could leverage this to provide an API invokable by libgfchangelog (once the interaction is RPC based) to get a list of changelogs for a given time period (similar to what history API does today).
> The benefit that this provides is that the consumers need not maintain state (the API takes care of that) of the amount of changelogs [to be] processed and make use of this API to get freshly consumable changelogs.
> : esp for lowlevel API (http://gluster.org/community/documentation/index.php/Features/Gnotify)
> Gluster-devel mailing list
> Gluster-devel at gluster.org
More information about the Gluster-devel