• Documentation
  • Contact
  • About
  • Developers
  • Download


From GlusterDocumentation


Hooks - Volume lifecycle extensions.


Enables users to run custom scripts on certain events. Events can be thought of as points in the execution of volume commands like create, start, stop, add-brick, remove-brick, set etc. Each of the above volume commands have two points in time during their execution namely pre and post.

Pre refers to the point in time just before the corresponding volume command has taken effect on a peer.

Post refers to the point in time just after the corresponding volume command has taken effect on a peer.


Vijay Bellur (

Krishnan Parthasarathi (

Current status

A working version is part of the codebase. See for patches that have already gone into implementing Hooks feature.

Detailed Description

glusterd didn't have a mechanism by which users could perform 'administrative tasks' before and after the successful completion of a gluster command. The interface planned would be similar to init scripts, where there would be a collection of scripts present under a 'special' directory that would be executed on an 'event'.

Directories to hold the scripts mentioned above would be created for each gluster command under glusterd's 'working dir' as follows: (eg.) /var/lib/glusterd/create/pre /var/lib/glusterd/create/post

Scripts whose name begin with 'S' are enabled and anything else would be disabled. The enabled scripts under the above directories would be run before (pre) and after (post) the volume created. The scripts would receive a command line argument as below:

start volume: --first=yes if the volume is the first to be started
                 and --first=no otherwise
stop volume: --last=yes if the volume is the last to be stopped
                 and --last=no otherwise
set volume: -o key=value ... for every key, value supplied in
               volume set command

The other volume commands corresponding to events supply --volname=VOLNAME as the only argument to the hook scripts.

Schematic representation

Let us take a cluster containing two peers namely A and B.

Command executed on A: gluster volume create vol A:brick1 B:brick2

On peer A: t0 - pre event t1 - commit operation corresponding to the volume command t2 - post event

On peer B: t3 - pre event t4 - commit operation corresponding to the volume command t5 - post event

Benefit to GlusterFS

Allows users to customise their deployments of volumes to suit their needs via the Hooks mechanism without having to expect glusterd to be aware of their specific needs.


Nature of proposed change

  <modification to existing code, new translators ...>

Implications on manageability

  <Glusterd, GlusterCLI, Web Console, REST API>

Implications on presentation layer


Implications on persistence layer

/var/lib/glusterd/hooks/<hooks-version-no>/<event>/{pre,post} are created


hooks-version-no is 1

event can be one of create, start, stop, add-brick, remove-brick, set

Implications on 'GlusterFS' backend


Modification to GlusterFS metadata


Implications on 'glusterd'

Glusterd iterates over executables (subject to naming conventions) that are placed under the <event>/{pre, post} before and after the commit stage of a gluster volume 'transaction' in each peer (glusterd).

How To Test

See #Schematic representation for functional spec of the runtime. Need to verify if the order of events being 'triggered' are same as explained in the schematic.

Other properties of the runtime that needs to be checked are:

- How name of script (presence of leading 'S') affects execution of the script?

- Order of execution hook-scripts.

User Experience

 No perceivable change in the glusterd cli.




 <Documentation for the feature>



Comments and Discussion


Copyright © Gluster, Inc. All Rights Reserved.