> +Current state and shortcomings > +============================== > + > +Currently, Ganeti allows customization of operations by running scripts > +in sub-directories of ``@SYSCONFDIR@/ganeti/hooks``. These > +sub-directories are named ``$hook-$phase.d``, where ``$phase`` is either > +``pre`` or ``post`` and ``$hook`` matches the directory name given for > +a hook (e.g. ``cluster-verify-post.d`` or ``node-add-pre.d``). Post > +hooks for opcodes don't run in case of the job process die. > + > +:doc:`hooks` design document describes currently existing hooks in more
s/^/The / Also join the two paragraphs to avoid one-sentence paragaphs; semantically, this sentence also belongs to the previous paragraph. > +details. > + > +In some situations, e.g., reporting to upper level tools controlling > +Ganeti, it is desirable to run hooks before and after each opcode > +execution. Users currently work around this problem by creating symbolic > +links for each opcode directory. But in that case a problem of the job > +processes death remains. In that case post-opcode hooks wouldn't run s/case/case,/ > +because the opcode execution didn't finish. > + > +Proposed changes > +================ > + > +Introduce the new type of hooks, the *global* hooks, that run before s/I/We propose to i/ > +and after each opcode execution even in case of opcode process death. > + > +Organization of such hooks will be preserved the same as for s/O/The o/ s/$/ the/ Also join the two paragraphs. > +:ref:`existing per-opcode hooks <hooks-organization>`. The same don't add trailing whitespace > +:ref:`common variables <common-variables>` will be available as for the > +usual hooks. In addition to common variables, > +:ref:`specialized variables <specialized-variables>`, corresponding to > +the surrounded opcode, will also be provided. See > +:ref:`per-opcode hooks parameters documentation <opcode-params>` for > +more details. > + > +Additional variables > +~~~~~~~~~~~~~~~~~~~~ > + > +Two additional variables are introduced for both pre and post hooks > +in order to identify the current job: > + > +JOB_ID > + Id of the job current opcode belongs to. > + > +OPCODE > + The name of current opcode in the uppercase format > + (e.g. OP_NODE_MIGRATE). See :ref:`operation list <opcode-params>` > + from the original ':doc:`hooks`' design document for the exhaustive > + list of operations. > + > +Due to the fact that global hooks will be executed even after job > +process die, new environmental variable is introduced for the *global* replace "job proccess die" by "a job process has died" s/new/a new/ > +post hooks: > + > +STATUS > + String containing status of the opcode execution: ``succeeded``, > + ``failed`` or ``disappeared``. > + > + The ``succeded`` status means that the logical unit corresponding to > + opcode succesfully finished. > + > + The ``failed`` status means that the corresponding logical unit caused > + an exception which has been logged. > + > + The ``disappeared`` status means that opcode process has died during > + the logical unit execution. Otherwise looks good. However, please also specify which entity will run the hooks in each case. Thanks, Klaus -- Klaus Aehlig Google Germany GmbH, Dienerstr. 12, 80331 Muenchen Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschaeftsfuehrer: Matthew Scott Sucherman, Paul Terence Manicle
