> +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` documents currently existing hooks in more details.
References to other documents are spliced in as the document title with a link to the referenced document. Please make sure, that this results in a corrent English sentence. > +Current situation leads to hooks simlinked into each opcode subdirectory s/C/The c/ Also, please better describe the scenario you're addressing. E.g., In some situations, e.g., reporting to upper level tools controlling Ganeti, it is desirable to run hooks before and after each job. Users currently work around this problem by creating symbolic links for each opcode directory; the problem of dying jobs still remains. > +in case in which the hooks should surround each job execution > +independent from opcode. > + > +Proposed changes > +================ > + > +Introduce the new type of hooks, the *global* hooks, universal for all > +the opcodes that will be run before and after each Ganeti job execution. This sentence is not clear. Is the new hook run before/after each opcode or before/after each job? Note that a job can have several opcodes. Please clarify. > +Organization of such hooks will be preserved the same > +:ref:`Ganeti customisation using hooks <common-variables>` as for usual > +hooks. In addition to common variables, corresponding > +:ref:`Ganeti customisation using hooks <specialized-variables>` will > +also be provided. Same splicing problem. Please fix. > + > +Additional variables > +~~~~~~~~~~~~~~~~~~~~ > + > +Due to the fact that global hooks will be executed even after job > +peocess die, new environmental variable is introduced for thei post > +hooks: > + > +JOB_STATUS > + String containing status of the job: Either ``error`` or ``finished`` There are two kind of errors: an opcode can fail but the failure is managed by the opcode process itself (this is the common case of error) or a job process can be found to have disappeared without finishing a job. Shouldn't we distinguish between those kinds of errors? Also describe which entity will run which hooks in which case. -- 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
