Revision c2610080
b/doc/design-reason-trail.rst | ||
---|---|---|
80 | 80 |
Implementation |
81 | 81 |
============== |
82 | 82 |
|
83 |
The OpCode base class will be modified to include a new field, OP_REASON.
|
|
83 |
The OpCode base class will be modified to include a new parameter, "reason".
|
|
84 | 84 |
This will receive the reason trail as built by all the previous steps. |
85 | 85 |
|
86 | 86 |
When an OpCode is added to a job (in jqueue.py) the job number and the opcode |
87 | 87 |
index will be recorded as the reason for the existence of that opcode. |
88 | 88 |
|
89 |
The implementation of this design will start from the operations that affect the |
|
90 |
instance status. They will be changed so that the "reason" is passed to them. |
|
91 |
They will then export the new expected instance status, together |
|
92 |
with the associated reason for the monitoring daemon. |
|
89 |
From the command line tools down to the opcodes, the implementation of this |
|
90 |
design will be shared by all the components of the system. After the opcodes |
|
91 |
have been enqueued in a job queue and are dispatched for execution, the |
|
92 |
implementation will have to be OpCode specific because of the current |
|
93 |
structure of the ganeti backend. |
|
94 |
|
|
95 |
The implementation of opcode-specific parts will start from the operations that |
|
96 |
affect the instance status (as required by the design document about the |
|
97 |
monitoring daemon, for the instance status data collector). Such opcodes will |
|
98 |
be changed so that the "reason" is passed to them and they will then export |
|
99 |
the reason trail on a file. |
|
100 |
|
|
101 |
The implementation for other opcodes will follow when required. |
|
93 | 102 |
|
94 | 103 |
.. vim: set textwidth=72 : |
95 | 104 |
.. Local Variables: |
Also available in: Unified diff