"reason" attached to it (at opcode level). This can be used for
example to distinguish an admin request, from a scheduled maintenance
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
- example a cli shutdown operation will have "cli:shutdown" as a reason,
- a cli failover operation will have "cli:failover". Operations coming
- from the remote API will use "rapi" instead of "cli". Of course
- setting a real site-specific reason is still preferred.
+ just use the information it has about the source of the request.
+ This reason information will be structured according to the
+ :doc:`Ganeti reason trail <design-reason-trail>` design document.
- 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
them. They will then export the new expected instance status, together
The instance status will be on each node, for the instances it is
primary for, and its ``data`` section of the report will contain a list
-of instances, with at least the following fields for each instance:
+of instances, named ``instances``, with at least the following fields for
+each instance:
``name``
The name of the instance.
The timestamp of the last known change to the instance state.
``state_reason``
- The last known reason for state change, described according to the
- following subfields:
-
- ``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).
+ The last known reason for state change of the instance, described according
+ to the JSON representation of a reason trail, as detailed in the :doc:`reason
+ trail design document <design-reason-trail>`.
``status``
It represents the status of the instance, and its format is the same as that
``1``
otherwise.
-Storage status
-++++++++++++++
+Storage collectors
+++++++++++++++++++
-The storage status collectors will be a series of data collectors
-(drbd, rbd, plain, file) that will gather data about all the storage types
-for the current node (this is right now hardcoded to the enabled storage
-types, and in the future tied to the enabled storage pools for the nodegroup).
+The storage collectors will be a series of data collectors
+that will gather data about storage for the current node. The collection
+will be performed at different granularity and abstraction levels, from
+the physical disks, to partitions, logical volumes and to the specific
+storage types used by Ganeti itself (drbd, rbd, plain, file).
The ``name`` of each of these collector will reflect what storage type each of
them refers to.
The ``category`` field of these collector will be ``storage``.
-The ``kind`` field will be ``1`` (`Status reporting collectors`_).
-
-The ``data`` section of the report will provide at least the following fields:
-
-``free``
- The amount of free space (in KBytes).
-
-``used``
- The amount of used space (in KBytes).
-
-``total``
- The total visible space (in KBytes).
+The ``kind`` field will depend on the specific collector.
-Each specific storage type might provide more type-specific fields.
+Each ``storage`` collector's ``data`` section will provide collector-specific
+fields.
In case of error, the ``message`` subfield of the ``status`` field of the
report of the instance status collector will disclose the nature of the error
for lvm storage, "unreachable" for network based storage or "filesystem error"
for filesystem based implementations.
+Diskstats collector
+*******************
+
+This storage data collector will gather information about the status of the
+disks installed in the system, as listed in the /proc/diskstats file. This means
+that not only physical hard drives, but also ramdisks and loopback devices will
+be listed.
+
+Its ``kind`` in the report will be ``0`` (`Performance reporting collectors`_).
+
+Its ``category`` field in the report will contain the value ``storage``.
+
+When executed in verbose mode, the ``data`` section of the report of this
+collector will be a list of items, each representing one disk, each providing
+the following fields:
+
+``major``
+ The major number of the device.
+
+``minor``
+ The minor number of the device.
+
+``name``
+ The name of the device.
+
+``reads``
+ This is the total number of reads completed successfully.
+
+``mergedReads``
+ Reads which are adjacent to each other may be merged for efficiency. Thus
+ two 4K reads may become one 8K read before it is ultimately handed to the
+ disk, and so it will be counted (and queued) as only one I/O. This field
+ specifies how often this was done.
+
+``secRead``
+ This is the total number of sectors read successfully.
+
+``timeRead``
+ This is the total number of milliseconds spent by all reads.
+
+``writes``
+ This is the total number of writes completed successfully.
+
+``mergedWrites``
+ Writes which are adjacent to each other may be merged for efficiency. Thus
+ two 4K writes may become one 8K read before it is ultimately handed to the
+ disk, and so it will be counted (and queued) as only one I/O. This field
+ specifies how often this was done.
+
+``secWritten``
+ This is the total number of sectors written successfully.
+
+``timeWrite``
+ This is the total number of milliseconds spent by all writes
+
+``ios``
+ The number of I/Os currently in progress.
+ The only field that should go to zero, it is incremented as requests are
+ given to appropriate struct request_queue and decremented as they finish.
+
+``timeIO``
+ The number of milliseconds spent doing I/Os. This field increases so long
+ as field ``IOs`` is nonzero.
+
+``wIOmillis``
+ The weighted number of milliseconds spent doing I/Os.
+ This field is incremented at each I/O start, I/O completion, I/O merge,
+ or read of these stats by the number of I/Os in progress (field ``IOs``)
+ times the number of milliseconds spent doing I/O since the last update of
+ this field. This can provide an easy measure of both I/O completion time
+ and the backlog that may be accumulating.
+
DRBD status
***********
Returns the report of the collector ``[collector_name]`` that belongs to the
specified ``[category]``.
-If a collector does not belong to any category, ``collector`` will be used as
-the value for ``[category]``.
+The ``category`` has to be written in lowercase.
+
+If a collector does not belong to any category, ``default`` will have to be
+used as the value for ``[category]``.
`Status reporting collectors`_ will provide their output in non-verbose format.
The verbose format can be requested by adding the parameter ``verbose=1`` to the
projects / ganeti-local / blobdiff