From c26100801c80e171c1ce83c292c71d07192ee411 Mon Sep 17 00:00:00 2001 From: Michele Tartara <mtartara@google.com> Date: Fri, 22 Mar 2013 19:26:34 +0100 Subject: [PATCH] More specifics on the implementation of the reason trail Adding the reason trail as a parameter instead of as a new class attribute fits better with the current structure of the system. Also, the description of what part of the implementation will be OpCode specific and which will be shared is added. Signed-off-by: Michele Tartara <mtartara@google.com> Reviewed-by: Helga Velroyen <helgav@google.com> --- doc/design-reason-trail.rst | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/doc/design-reason-trail.rst b/doc/design-reason-trail.rst index 860fa88ed..55988322b 100644 --- a/doc/design-reason-trail.rst +++ b/doc/design-reason-trail.rst @@ -80,16 +80,25 @@ remote API, would have a reason trail like:: Implementation ============== -The OpCode base class will be modified to include a new field, OP_REASON. +The OpCode base class will be modified to include a new parameter, "reason". This will receive the reason trail as built by all the previous steps. When an OpCode is added to a job (in jqueue.py) the job number and the opcode index will be recorded as the reason for the existence of that opcode. -The implementation of this design will start from the operations that affect the -instance status. They will be changed so that the "reason" is passed to them. -They will then export the new expected instance status, together -with the associated reason for the monitoring daemon. +From the command line tools down to the opcodes, the implementation of this +design will be shared by all the components of the system. After the opcodes +have been enqueued in a job queue and are dispatched for execution, the +implementation will have to be OpCode specific because of the current +structure of the ganeti backend. + +The implementation of opcode-specific parts will start from the operations that +affect the instance status (as required by the design document about the +monitoring daemon, for the instance status data collector). Such opcodes will +be changed so that the "reason" is passed to them and they will then export +the reason trail on a file. + +The implementation for other opcodes will follow when required. .. vim: set textwidth=72 : .. Local Variables: -- GitLab