Re: [PATCH 2/2] virhook: support hooks placed in several files
But that leads me to think that maybe after all we should run all
hook
scripts and report failure if either of them failed.
we would not have paired "prepare" and "release"
calls for both scripts.
I agree with you. I will do this scheme - always run all scripts.
Dmitry
________________________________________
From: Michal Privoznik <mprivozn(a)redhat.com>
Sent: Tuesday, June 23, 2020 1:03 PM
To: Dmitry Nesterenko; libvir-list(a)redhat.com
Subject: Re: [PATCH 2/2] virhook: support hooks placed in several files
On 6/23/20 10:24 AM, Dmitry Nesterenko wrote:
> virFileIsExecutable() is enough
I agree and will fix it in next version of patch.
> I'm not sure we want this check for output
If we are given param for xml output - it is call hook for "migrate" or
"restore" and any fail
from script can break the process. So we can break running of all scripts immediately
after
first fail. But if we don't have xml param for output - it can be call hook for stop
with ignoring return code of script. And I think in this case will better to run all
scripts.
Well, apparently output != NULL is not enough to tell whether we can
stop or not. For instance: qemuProcessStartHook() which is called when a
domain is starting up. The output is NULL (the script can't change the
domain XML), but if it fails the start of the domain is aborted.
But that leads me to think that maybe after all we should run all hook
scripts and report failure if either of them failed. Because of
instance, if I have two hook scripts, one sets up one resource for the
domain, the other sets up some other resource for the domain; and both
of them would be run on domain startup I want them both to run on domain
shutdown to release the resources.
But, if say the first script fails on domain startup, so the startup
process is aborted, qemuProcessStop() is called which executes both
scripts again. I mean, we would not have paired "prepare" and
"release"
calls for both scripts.
We can declare that hook scripts have to take care of that and to some
extend they already are doing so, because even now, with one hook script
per driver the "release" implementation must cope with unbalanced call,
because if domain start up fails slightly earlier, before "prepare" is
called, then "release" is called anyway.
Michal