<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 31, 2015 at 7:35 PM, Shyam <span dir="ltr"><<a href="mailto:srangana@redhat.com" target="_blank">srangana@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/31/2015 12:24 AM, Samikshan Bairagya wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi everyone,<br>
<br>
I have been working on this project for the past few weeks that aims at<br>
improving the eventing framework for GlusterFS through storaged [0][1].<br>
Through a DBus API over the existing GlusterFS CLI, storaged could help<br>
with better notifications for gluster events.<br>
</blockquote>
<br></span>
Is this a Linux only solution? What is the alternative for NetBSD? (a quick search for systemd/storaged on NetBSD yielded nothing of significance)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The plan:<br>
=========<br>
<br>
storaged exports objects implementing the respective interfaces for<br>
Linux block devices, drives, RAID arrays, etc. on the DBus. More objects<br>
implementing other interfaces can be exported through modules. The<br>
"glusterfs" module in storaged will populate the DBus with GlusterFS<br>
specific objects implementing the required interfaces. As an example,<br>
the "iscsi" module in storaged adds DBus objects implementing the<br>
org.storaged.Storaged.ISCSI.Session interface[2].<br>
<br>
Once DBus objects are exported to the DBus for GlusterFS volumes and<br>
bricks, implementing the respective interfaces, it would be convenient<br>
for interested clients to receive event notifications through DBus<br>
signals or method calls. This enables clients to get updates wrt changes<br>
on the glusterfs side in real time over the existing logging framework.<br>
</blockquote>
<br></span>
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.</blockquote><div><br></div><div>+1 , same here<br><br></div><div>Also to add, it would be good to provide the below :<br></div><div><br>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!<br><br></div><div>2) An example of how the client will use it and what it takes for the client to use/consume this interface ?<br><br></div><div>3) A mapping of gluster events (hooks or otherwise ?) and storaged / dbus events<br><br></div><div>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<br></div><div>in the response to #1 above.<br></div><div><br></div><div>thanx,<br></div><div>deepak<br></div><br></div><br></div></div>