Re: Feature page on Volume lifecycle extensions (aka Hooks)

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

 



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.




[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