Revision 2bd9ec7c

b/doc/design-monitoring-agent.rst
224 224 
  "reason" attached to it (at opcode level). This can be used for
225 225 
  example to distinguish an admin request, from a scheduled maintenance
226 226 
  or an automated tool's work. If this reason is not passed, Ganeti will
227 
  just use the information it has about the source of the request: for
228 
  example a cli shutdown operation will have "cli:shutdown" as a reason,
229 
  a cli failover operation will have "cli:failover". Operations coming
230 
  from the remote API will use "rapi" instead of "cli". Of course
231 
  setting a real site-specific reason is still preferred.
227 
  just use the information it has about the source of the request.
228 
  This reason information will be structured according to the
229 
  :doc:`Ganeti reason trail <design-reason-trail>` design document.
232 230 
- RPCs that affect the instance status will be changed so that the
233 231 
  "reason" and the version of the config object they ran on is passed to
234 232 
  them. They will then export the new expected instance status, together
......
270 268 
  The timestamp of the last known change to the instance state.
271 269 

  		





  272
  270
  
    
``state_reason``


  		





  273
  
  
    
  The last known reason for state change, described according to the


  		





  274
  
  
    
  following subfields:


  		





  275
  
  
    

  		





  276
  
  
    
  ``text``


  		





  277
  
  
    
    Either a user-provided reason (if any), or the name of the command that


  		





  278
  
  
    
    triggered the state change, as a fallback.


  		





  279
  
  
    

  		





  280
  
  
    
  ``jobID``


  		





  281
  
  
    
    The ID of the job that caused the state change.


  		





  282
  
  
    

  		





  283
  
  
    
  ``source``


  		





  284
  
  
    
    Where the state change was triggered (RAPI, CLI).


  		





  
  271
  
    
  The last known reason for state change of the instance, described according


  		





  
  272
  
    
  to the JSON representation of a reason trail, as detailed in the :doc:`reason trail


  		





  
  273
  
    
  design document <design-reason-trail>`.


  		





  285
  274
  
    

  		





  286
  275
  
    
``status``


  		





  287
  276
  
    
  It represents the status of the instance, and its format is the same as that


  		












Also available in:
  Unified diff