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

[Samikshan Bairagya]

On 09/03/2015 11:47 AM, Deepak Shetty wrote:
> 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)
>>

Hi,

This is essentially  a feature addition to storaged to support 
glusterfs; though which gluster events can be tracked better. Hence yes, 
this is a Linux only solution.

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

Events notifications through signals will be sent out by DBus objects 
exported by storaged whenever one or more properties held by these 
objects representing the various gluster entities (volumes, bricks, 
etc.) change. So different clients having interest in different kinds of 
events can register for corresponding signals and take action accordingly.

However I feel that once this feature is completely implemented in 
storaged, notifications for events like brick-failure and 
process-related events could prove useful. I will think of a more 
comprehensive list of events that clients might find useful.

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

I will provide an example through the prototype I had introduced 
earlier. Though the process of consuming interfaces for event 
notifications will be much more evolved in the future when this will no 
longer remain in the prototype/hacky stage.

Consider the following python script as a client interested in knowing 
when new objects are created by storaged:

####################################################################

#!/usr/bin/env python

import gobject
import dbus
import dbus.mainloop.glib


def handle_object_creation (obj_path, stuff):
     print "New object created at ", obj_path

dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.Bus(dbus.Bus.TYPE_SYSTEM)

bus_object = bus.get_object('org.storaged.Storaged', 
'/org/storaged/Storaged')
bus_object.connect_to_signal ('InterfacesAdded', handle_object_creation, 
dbus_interface='org.freedesktop.DBus.ObjectManager')

loop = gobject.MainLoop()
loop.run()

#####################################################################

When the prototype is tested with this script running in the background 
messages (like "New object created at 
/org/storaged/Storaged/glusterfs/volume/gfsvolfoo") are printed for 
every new volume created.


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

Even though this might be too early to provide any such predictions, if 
in the future storaged can retrieve information related to cache tiering 
in gluster then it might be possible to implement this in order to send 
out notifications for such events. Difficult to implement or no, 
providing notifications for these kind of events is a part of the plan.

I hope this provides better clarity.

Thanks and Regards,

Samikshan