> +
> +Other problem is that some opcodes don't support hooks. That makes it

s/Other/Another

> +impossible for external tools to setup hook for each opcode execution
> +that might be useful, e.g. for monitoring puproses.
> +
> +Proposed changes
> +================
> +
> +We propose to introduce the new type of hooks, the *global* hooks, that

s/the new/a new

> +run before and after each opcode execution even in case of opcode
> +process death. The organization of such hooks will be preserved the
> +same as for the :ref:`existing per-opcode hooks <hooks-organization>`.
> +The same :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.
> +
> +For the opcodes that are currently unsupported by hooks, and thus, don't
> +presented in :ref:`opcodes list <opcode-params>`, only
> +:ref:`common variables <common-variables>` will be available in the
> +corresponding *global* hooks. *OBJECT_TYPE* variable for such hooks will
> +be initialized with special ``NOT_APPLICABLE`` value. The hooks will be
> +executed only on master daemon as their opcodes won't provide any lists
> +containing target nodes.
> +
> +Additional variables
> +~~~~~~~~~~~~~~~~~~~~
> +
> +The additional variable is introduced for both pre and post hooks
> +in order to identify the current job:
> +
> +GANETI_JOB_ID
> +  Id of the job current opcode belongs to.
> +
> +Due to the fact that global hooks will be executed even after job
> +process has dead, a new environmental variable is introduced for the
> +*global* post hooks:
> +
> +GANETI_POST_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 job process has died during
> +  the logical unit execution.
> +
> +Behaviour details
> +=================

s/=/~/g

The "behaviour details" are also part of the "Proposed changes" and
the level of the heading should reflect that.

> +
> +Code executing the logical unit will start a process which will be

s/Code/The code

> +responsible for the *global* hooks execution. All the pre hooks will end
> +their execution before the start of the opcode execution on each node.
> +All the post hooks will start after the end of logical unit execution or
> +after the job process death. In case of the job process death, the hooks
> +will not be executed for the further opcodes in the job.

Rest LGTM. Thanks.

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

Reply via email to