From e245ee9be46ef887626fe2693c9a76aaa8a969cb Mon Sep 17 00:00:00 2001 From: Tim Moore II Date: Thu, 7 Apr 2016 14:56:20 -0400 Subject: [PATCH] Events.rst work -Adding additional documentation of dispatcher subsystem and sample code blocks --- api/events.rst | 100 +++++++++++++++++++++++++------------------------ 1 file changed, 52 insertions(+), 48 deletions(-) diff --git a/api/events.rst b/api/events.rst index 22cde3e..02a093a 100644 --- a/api/events.rst +++ b/api/events.rst @@ -65,7 +65,7 @@ Here is an example reply from the Life Preserver subsystem: Dispatcher ---------- -The Dispatcher subsystem is used by sysadm to process external commands and return specific information from the utility. +The Dispatcher subsystem is used by SysAdmâ„¢ to process external commands and return specific information from the utility. This is managed on the server as a separate process, and will not interrupt primary server tasks. To subscribe to the Dispatcher subsystem for event updates, use the following: @@ -80,58 +80,67 @@ To subscribe to the Dispatcher subsystem for event updates, use the following: "args" : ["dispatcher"] } -Dispatcher has two different kinds of websocket messages, general process notifications and specialized subsystem process notifications. -The general process notifications will appear as follows: +The Dispatcher event log will display three different states: "pending", "running", and "finished". +Depending upon the current state, the log can change in some minor but noteworthy ways. +The following sample logs will reflect the differences between these states: -**Websocket Event Message (Process Starting)** +**Dispatcher Response: "Pending" state** .. code-block:: json { - "namespace" : "events", - "name" : "dispatcher", - "id" : "none", - "args" : { - "process_id" : "", - "state" : "running" - } + "namespace" : "events", + "name" : "dispatcher", + "id" : "none", + "args" : { + "state" : "pending", + "cmd_list" : ["", ""], + "process_id" : "" + } } -.. - .. code-block:: json - - { - "namespace" : "events", - "name" : "dispatcher", - "id" : "none", - "args" : { - "time_started" : , - "cmd_list" : [ "", ""], - "process_id" : "", - "state" : "running" - } - } - -**Websocket Event Message (Process Complete)** +**Dispatcher Response: "Running" state** .. code-block:: json { - "namespace" : "events", - "name" : "dispatcher", - "id" : "none", - "args" : { - "time_finished" : , - "cmd_list" : [ "", ""], - "process_id" : "", - "state" : "finished", - "return_codes" - } + "namespace" : "events", + "name" : "dispatcher", + "id" : "none", + "args" : { + "state" : "running", + "cmd_list" : ["", ""], + "process_id" : "", + "time_started" : "", + "current_cmd" : "", + "" : "", + "" : "", + "return_codes/" : "" + } } -Particular classes within sysadm may return information through the Dispatcher events system. These types of messages are slightly different in output format, which is noted here: +**Dispatcher Response: "Finished" state** -**Websocket Event Message** +.. code-block:: json + + { + "namespace" : "events", + "name" : "dispatcher", + "id" : "none", + "args" : { + "state" : "finished", + "time_finished" : "", + "return_codes" : ["", ""], + "process_id" : "" + } + } + + +Individual classes such as iohyve will move these dispatcher elements into a "process_details" section. +Tailored sample responses will be provided in these classes' individual documentation pages. +A generalized sample is as follows: + +**Dispatcher Class Event Message** .. code-block:: json @@ -140,15 +149,10 @@ Particular classes within sysadm may return information through the Dispatcher e "name" : "dispatcher", "id" : "none", "args" : { - "event_system" : /, - "state" : "running" OR "finished", - - "process_details" : { - "time_started" : , - "cmd_list" : [ "", ""], - "process_id" : "", - "state" : "running" - } + "event_system" : "/", + "state" : "", + "" : "", + "process_details" : "" } }