[Gluster-devel] Introducing an eventing framework for GlusterFS through storaged

[Deepak Shetty]

On Mon, Aug 31, 2015 at 7:35 PM, Shyam <srangana at redhat.com> wrote:

> On 08/31/2015 12:24 AM, Samikshan Bairagya wrote:
>
>> Hi everyone,
>>
>> I have been working on this project for the past few weeks that aims at
>> improving the eventing framework for GlusterFS through storaged [0][1].
>> Through a DBus API over the existing GlusterFS CLI, storaged could help
>> with better notifications for gluster events.
>>
>
> Is this a Linux only solution? What is the alternative for NetBSD? (a
> quick search for systemd/storaged on NetBSD yielded nothing of significance)
>
>
>> The plan:
>> =========
>>
>> storaged exports objects implementing the respective interfaces for
>> Linux block devices, drives, RAID arrays, etc. on the DBus. More objects
>> implementing other interfaces can be exported through modules. The
>> "glusterfs" module in storaged will populate the DBus with GlusterFS
>> specific objects implementing the required interfaces. As an example,
>> the "iscsi" module in storaged adds DBus objects implementing the
>> org.storaged.Storaged.ISCSI.Session interface[2].
>>
>> Once DBus objects are exported to the DBus for GlusterFS volumes and
>> bricks, implementing the respective interfaces, it would be convenient
>> for interested clients to receive event notifications through DBus
>> signals or method calls. This enables clients to get updates wrt changes
>> on the glusterfs side in real time over the existing logging framework.
>>
>
> Can you provide a sample list of events that the clients would be
> interested in, or Gluster would need to provide? I am curious to know the
> level of integration sought here based on the type of events that we intend
> to publish.


+1 , same here

Also to add, it would be good to provide the below :

1) A list of usecases where this will be used/ useful. It seems this can be
helpful in openstack , but not fully clear to me, yet!

2) An example of how the client will use it and what it takes for the
client to use/consume this interface ?

3) A mapping of gluster events (hooks or otherwise ?) and storaged / dbus
events

4) For eg: We have tiering in gluster, is it possible for the client to
know when a file was moved from hot to cold tier or vice versa using this
interface, if not, what would it take to do so ? Something liek this, i
would expect
in the response to #1 above.

thanx,
deepak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150903/09b71ed6/attachment.html>