Skip to content
Snippets Groups Projects
Commit 2bd9ec7c authored by Michele Tartara's avatar Michele Tartara
Browse files

Update "reason" field in instance status design


Now the reason field is implemented according to the reason trail design
document.

Signed-off-by: default avatarMichele Tartara <mtartara@google.com>
Reviewed-by: default avatarHelga Velroyen <helgav@google.com>
parent 0791b57f
No related branches found
No related tags found
No related merge requests found
...@@ -224,11 +224,9 @@ As such we propose that: ...@@ -224,11 +224,9 @@ As such we propose that:
"reason" attached to it (at opcode level). This can be used for "reason" attached to it (at opcode level). This can be used for
example to distinguish an admin request, from a scheduled maintenance example to distinguish an admin request, from a scheduled maintenance
or an automated tool's work. If this reason is not passed, Ganeti will or an automated tool's work. If this reason is not passed, Ganeti will
just use the information it has about the source of the request: for just use the information it has about the source of the request.
example a cli shutdown operation will have "cli:shutdown" as a reason, This reason information will be structured according to the
a cli failover operation will have "cli:failover". Operations coming :doc:`Ganeti reason trail <design-reason-trail>` design document.
from the remote API will use "rapi" instead of "cli". Of course
setting a real site-specific reason is still preferred.
- RPCs that affect the instance status will be changed so that the - RPCs that affect the instance status will be changed so that the
"reason" and the version of the config object they ran on is passed to "reason" and the version of the config object they ran on is passed to
them. They will then export the new expected instance status, together them. They will then export the new expected instance status, together
...@@ -270,18 +268,9 @@ of instances, with at least the following fields for each instance: ...@@ -270,18 +268,9 @@ of instances, with at least the following fields for each instance:
The timestamp of the last known change to the instance state. The timestamp of the last known change to the instance state.
``state_reason`` ``state_reason``
The last known reason for state change, described according to the The last known reason for state change of the instance, described according
following subfields: to the JSON representation of a reason trail, as detailed in the :doc:`reason trail
design document <design-reason-trail>`.
``text``
Either a user-provided reason (if any), or the name of the command that
triggered the state change, as a fallback.
``jobID``
The ID of the job that caused the state change.
``source``
Where the state change was triggered (RAPI, CLI).
``status`` ``status``
It represents the status of the instance, and its format is the same as that It represents the status of the instance, and its format is the same as that
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment