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

[Krishnan Parthasarathi]

----- 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.

> 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.
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.

> 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].

cheers,
krish