On 09/03/2015 11:47 AM, Deepak Shetty wrote:
On Mon, Aug 31, 2015 at 7:35 PM, Shyam <srangana@xxxxxxxxxx> 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
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
