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

[Deepak C Shetty]

Regret the immense delay in responding... i was busy travelling and 
other things.. hence couldn't reply any earlier.

On 10/08/2012 04:55 PM, Krishnan Parthasarathi wrote:
>
> ----- Original Message -----
>> From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
>> To: "krish" <kparthas at redhat.com>
>> Cc: gluster-devel at nongnu.org
>> Sent: Wednesday, August 29, 2012 3:04:26 PM
>> Subject: Re: [Gluster-devel] Feature page on Volume lifecycle extensions (aka Hooks)
>>
>> 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)
> How is this a security issue? Are you assuming the admin has not protected
> /var/lib/glusterd directory from the access of (malicious/trigger-happy)
> non-root users? In that case her/his storage node is already compromised.

For me, somethign running on in the bakcground for my volume event w/o 
me authorizing or knowing is a security issue :)

>
>> 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 be good to have a volume option which decides whether or not
> to run hook scripts for events of the volume. For create event we may
> need to rely on a global option (viz applicable for all volumes) to
> decide whether or not we run hook scripts on the volume that is being
> created.

Thanks for agreeing.

> To clarify, the above mechanism doesn't make things more trustworthy.
> It only gives storage admins more control on which volumes' events
> trigger hook scripts.

Well 'trustworthy' is subjective... depends on how you see it.
Again for me, allowing this control makes the entire stuff more 
trustful, since I can control what i want and what i don't want.

>
>> 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.
> Hook scripts run only once when an event occurs for any volume. Of course,
> this can be controlled from the script side as well. The script could
> store (persistently), a list of volumes it wants to be applicable to.
>
>> 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.
>>
>>
> Would you like to submit a patch that would allow user to control
> the running of hooks on a volume? All of hooks related code is
> present in glusterd-hooks.[ch].

I can try, but can't commit anythign right now, due to other work 
pressure. If you think this is good, pls go ahead and update the feature 
page .. maybe a TODO ?
Or do you want me to open a BZ for this ?

>
> cheers,
> krish
>
>
>