On 08/29/2012 02:31 PM, krish wrote:
On 08/29/2012 01:21 PM, Deepak C Shetty wrote:
On 08/28/2012 06:02 PM, krish wrote:
On 08/27/2012 01:42 PM, Deepak C Shetty wrote:
On 08/24/2012 11:56 AM, Krishnan Parthasarathi wrote:
Hi list,
The following wiki page provides detailed information on "Volume
life cycle extensions"
or more fondly referred to as Hooks. Hooks are scripts/executables
that would
be run on the trigger of events like volume-start, volume-stop,
etc. This allows admin
to customise her volume 'deployment' work-flow. Of course it is
not arbitrarily expressive/powerful
yet.
http://www.gluster.org/community/documentation/index.php/Features/Hooks
This (conceptually) is similar to hooks provided by oVirt/VDSM. I
have a naive Q tho'
How to enable/disable a hook for a particular volume ? Is it that
if i don't set any key=value for a particular volume, the hook
won't come into action. In other words hooks will use key=value to
determine what they need to do ?
Scripts whose name begin with 'S' are enabled and anything else
would be disabled
I have updated the wiki with the answer to your question. Thanks for
asking!
(See
http://www.gluster.org/community/documentation/index.php/Features/Hooks#Detailed_Description)
Hmm, still not clear. Let me reword my Q.
Scripts that are enabled are not tied to a particular volume, rite ?
Assuming that, if a script is enabled, then it would run/invoke for
all volumes. How do i control the running of a script at the volume
level ?
Say i need to run a script for all volume except one.. how do i
control that ?
The scripts are tied to events (volume commands like set, start, stop
etc) and __not__ to any volume.
The volume on which the script is 'applied' (or called for) is the
volume on which the glusterd command is
executed. The script is supplied volname as a CLI argument, which it
could use to conditionally execute actions
in the script for the given volume.
'guess i missed seeing that (volname passed as arg) while going thru the
wiki, it would be good to add more info on how this can be used to
control what runs for a particular volume.
This also means that from the volume creation / life-cycle perspective,
there is no way to control whether or not hook is allowed to run, won't
this be a security issue ?
Volume Name is public and/or can be easily found. If someone writes a
script starting with 'S', one can do any havoc for a particular volume (
either intentionally or by mistake)
Won't it be better to have volume itself control whether or not hooks
are enabled for itself ? A volume set ... option maybe ?
Volume creation, set and other stuff are done by Storage admin, so its
more trustworthy to control things from there, I feel.
It would also help if we need to disable the hook for a volume for a
small period of time, and enable it again, otherwise in the current
method hook would always run.
In VDSM hooks, its controllable on a per VM basis by using a custom
arg/param... hence user knows what he/she is doing when using hooks.
