gluster-devel
[Top][All Lists]
Advanced

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

Re: [Gluster-devel] Feature page on Volume lifecycle extensions (aka Hoo


From: Deepak C Shetty
Subject: Re: [Gluster-devel] Feature page on Volume lifecycle extensions (aka Hooks)
Date: Tue, 20 Nov 2012 16:02:23 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1

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" <address@hidden>
To: "krish" <address@hidden>
Cc: address@hidden
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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]