Re: Introducing an eventing framework for GlusterFS through storaged

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.


The implementation can be divided into 2 major steps:

1. Retrieving the GlusterFS state and populating the bus accordingly
--------------------------------------------------------------------

All volumes and bricks need to be exported as objects on the bus after
retrieving the glusterfs state. The volumes objects would be under the
object path /org/storaged/Storaged/glusterfs/volume/* and would be
implementing the org.storaged.Storaged.GlusterFS.Volume interface.
Similarly, bricks objects implementing the corresponding
o.s.S.GlusterFS.Brick should appear under path /o/s/S/glusterfs/brick/*.

2. Update storaged with GlusterFS state and send change notifications
---------------------------------------------------------------------

This step is important wrt event notifications. The exported DBus
objects implementing the corresponding interfaces hold properties. When
changes in the GlusterFS state are recorded in storaged, new objects
will be added, interfaces will be added to existing objects and/or
properties will be updated. These changes will send out corresponding
DBus signals. Clients registered on these signals can receive change
notifications accordingly.

Working prototype for the "glusterfs" module in storaged
========================================================

I have added a "glusterfs" module to storaged which can be considered to
be a very basic prototype to give an overview of how this can work.

Retrieving the glusterfs state
------------------------------

The prototype retrieves created GlusterFS volumes by parsing the output
of "gluster volume info all --xml"  and exports them as DBus objects
under /org/storaged/Storaged/glusterfs/volume/*. Right now the prototype
implementation contains only the volume name as one of the properties
for the objects.


Updating storaged and sending out change notifications
------------------------------------------------------

storaged responds to a DBus method call made by a script under
/var/lib/glusterd/hooks/1/create/post/S01StoragedReload.sh every time a
new volume is created by "reloading" the glusterfs module. This adds a
new object corresponding to the newly created volume. "InterfacesAdded"
signal emitted by the object at "/org/storaged/Storaged" can be caught
to be notified of such events.

Testing the prototype:
======================

1. Obtain the source and checkout the "glusterfs" branch from
https://github.com/samikshan/storaged.git

2. Install storaged:

$ ./auotogen.sh
$ ./configure --enable-glusterfs --prefix=/usr --sysconfdir=/etc
--localstatedir=/var
$ make
$ sudo make install

3. Add the script
https://github.com/samikshan/storaged/blob/glusterfs/modules/glusterfs/data/S01StoragedReload.sh
under /var/lib/glusterd/hooks/1/create/post/

4. Create one or more gluster volumes and start storaged in debug mode
by issuing the following command:

sudo /usr/libexec/storaged/storaged -r --force-load-modules

5. Use gdbus/qdbus to introspect the org.storaged.Storaged bus
connection. The gluster volumes should appear as DBus objects under the
object path /org/storaged/Storaged/glusterfs/volume/*

6. Create a new gluster volume and introspect the org.storaged.Storaged
connection again. A new DBus object corresponding to the new volume
created should now appear.

This prototype will hopefully extend itself to a full-fledged eventing
framework for glusterfs. If you have any feedback or queries on the
design or prototype please ask.

[0] https://storaged-project.github.io/
[1] https://storaged-project.github.io/doc/latest/index.html
[2]
http://storaged-project.github.io/doc/latest/gdbus-org.storaged.Storaged.ISCSI.Session.html


Thanks and Regards,

Samikshan Bairagya
Software Engineer,
Storage Engineering,
Red Hat India Pvt. Ltd.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel



[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux