From 00e2a7c357ecaee1d3fb57f78abeb4bbf112fb3e Mon Sep 17 00:00:00 2001
From: Sebastian Wagner <sebastian.wagner@suse.com>
Date: Thu, 7 Feb 2019 16:11:02 +0100
Subject: [PATCH] doc/mgr/orchestrator: Add Image

Signed-off-by: Sebastian Wagner <sebastian.wagner@suse.com>
---
 doc/mgr/orchestrator_modules.rst | 52 ++++++++++++++++++++++++++++++++
 src/pybind/mgr/orchestrator.py   |  7 ++---
 2 files changed, 55 insertions(+), 4 deletions(-)

diff --git a/doc/mgr/orchestrator_modules.rst b/doc/mgr/orchestrator_modules.rst
index c114a9bb7ea..138ff40ad6b 100644
--- a/doc/mgr/orchestrator_modules.rst
+++ b/doc/mgr/orchestrator_modules.rst
@@ -26,6 +26,39 @@ by subclasses.  The purpose of defining this common interface
 for different orchestrators is to enable common UI code, such as
 the dashboard, to work with various different backends.
 
+
+.. graphviz::
+
+    digraph G {
+        subgraph cluster_1 {
+            volumes [label="mgr/volumes"]
+            rook [label="mgr/rook"]
+            dashboard [label="mgr/dashboard"]
+            orchestrator_cli [label="mgr/orchestrator_cli"]
+            orchestrator [label="Orchestrator Interface"]
+            ansible [label="mgr/ansible"]
+            ssh [label="mgr/ssh"]
+            deepsea [label="mgr/deepsea"]
+
+            label = "ceph-mgr";
+        }
+
+        volumes -> orchestrator
+        dashboard -> orchestrator
+        orchestrator_cli -> orchestrator
+        orchestrator -> rook -> rook_io
+        orchestrator -> ansible -> ceph_ansible
+        orchestrator -> deepsea -> suse_deepsea
+        orchestrator -> ssh
+
+
+        rook_io [label="Rook"]
+        ceph_ansible [label="ceph-ansible"]
+        suse_deepsea [label="DeepSea"]
+
+        rankdir="TB";
+    }
+
 Behind all the abstraction, the purpose of orchestrator modules is simple:
 enable Ceph to do things like discover available hardware, create and
 destroy OSDs, and run MDS and RGW services.
@@ -127,6 +160,13 @@ Excluded functionality
   Ceph clusters).  Each drive is assumed to be visible only on
   a single node.
 
+Host management
+---------------
+
+.. automethod:: Orchestrator.add_host
+.. automethod:: Orchestrator.remote_host
+.. automethod:: Orchestrator.get_hosts
+
 Inventory and status
 --------------------
 
@@ -140,6 +180,11 @@ Inventory and status
 .. automethod:: Orchestrator.describe_service
 .. autoclass:: ServiceDescription
 
+Service Actions
+---------------
+
+.. automethod:: Orchestrator.service_action
+
 OSD management
 --------------
 
@@ -154,6 +199,13 @@ OSD management
    :members:
    :exclude-members: from_json
 
+Stateless Services
+------------------
+
+.. automethod:: Orchestrator.add_stateless_service
+.. automethod:: Orchestrator.update_stateless_service
+.. automethod:: Orchestrator.remove_stateless_service
+
 Upgrades
 --------
 
diff --git a/src/pybind/mgr/orchestrator.py b/src/pybind/mgr/orchestrator.py
index 9b3daabb3b4..296bcdaab33 100644
--- a/src/pybind/mgr/orchestrator.py
+++ b/src/pybind/mgr/orchestrator.py
@@ -56,8 +56,6 @@ class ReadCompletion(_Completion):
     ``Orchestrator`` implementations should inherit from this
     class to implement their own handles to operations in progress, and
     return an instance of their subclass from calls into methods.
-
-    Read operations are
     """
 
     def __init__(self):
@@ -245,9 +243,10 @@ class Orchestrator(object):
         Perform an action (start/stop/reload) on a service.
 
         Either service_name or service_id must be specified:
-        - If using service_name, perform the action on that entire logical
+
+        * If using service_name, perform the action on that entire logical
           service (i.e. all daemons providing that named service).
-        - If using service_id, perform the action on a single specific daemon
+        * If using service_id, perform the action on a single specific daemon
           instance.
 
         :param action: one of "start", "stop", "reload"
-- 
2.39.5