Make the design document consistent with the current global post hooks implementation.
Signed-off-by: Oleg Ponomarev <[email protected]> --- doc/design-global-hooks.rst | 43 +++++++++++++++++++++++++++++++------------ 1 file changed, 31 insertions(+), 12 deletions(-) diff --git a/doc/design-global-hooks.rst b/doc/design-global-hooks.rst index 1778fa4..fd06fc1 100644 --- a/doc/design-global-hooks.rst +++ b/doc/design-global-hooks.rst @@ -40,6 +40,7 @@ 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:`additional variables <additional-variables>` and :ref:`specialized variables <specialized-variables>`, corresponding to the surrounded opcode, will also be provided. See :ref:`per-opcode hooks parameters documentation <opcode-params>` for @@ -47,12 +48,20 @@ 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 +:ref:`common variables <common-variables>` and +:ref:`additional variables <additional-variables>` will be available +inside the *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. +For the *global* post hooks executing after a failure or death of +the job process, only :ref:`common variables <common-variables>` +(except OBJECT_TYPE) and +:ref:`additional variables <additional-variables>` will be provided. + +.. _additional-variables: + Additional variables ~~~~~~~~~~~~~~~~~~~~ @@ -71,23 +80,33 @@ GANETI_POST_STATUS ``failed`` or ``disappeared``. The ``succeded`` status means that the logical unit corresponding to - opcode succesfully finished. + opcode and the non-global post hooks for the opcodes are succesfully + finished. - The ``failed`` status means that the corresponding logical unit caused - an exception which has been logged. + The ``failed`` status means that the corresponding logical unit or + the non-global hooks caused an exception which has been logged. The ``disappeared`` status means that job process has died during - the logical unit execution. + the logical unit or the non-global hooks execution. Behaviour details ~~~~~~~~~~~~~~~~~ -The code executing the logical unit will start a process which will be -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. +*Global* pre hooks will be always executed just before the usual pre +hooks on the same nodes set. Then, the hooks execution result will be +ignored. In case of opcodes which don't support hooks, *global* pre +hooks also will be executed but only on the master node. + +With the post hooks situation is more complicated. In case of +``succeeded`` execution, *global* hooks will be executed just after the +usual post hooks have run and all the errors have checked. In case of +``failed`` status, *global* post hooks will be executed only on +the master node from the exception handler. Just after the *global* +post hooks execution, the exception will be raised again, as usual. In +case of ``disappeared`` job process, the scheduler will execute +the *global* post hooks in the separate process as soon as the job +process death is registered. The *global* post hooks will be executed +only for the opcodes with the initialized start_timestamp. .. vim: set textwidth=72 : .. Local Variables: -- 2.6.0.rc2.230.g3dd15c0
