[Gluster-devel] Feature page on Volume lifecycle extensions (aka Hooks)

[Deepak C Shetty]

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.