Updated Doctor user configuration doc

Change-Id: I71539412285c8f7865890880fdfc8c5268156f68
Signed-off-by: Bertrand Souville <souville@docomolab-euro.com>

diff --git a/docs/release/userguide/feature.userguide.rst b/docs/release/userguide/feature.userguide.rst
index 0dde4f2..0783e0f 100644 (file)
--- a/docs/release/userguide/feature.userguide.rst
+++ b/docs/release/userguide/feature.userguide.rst
@@ -9,7 +9,7 @@ Doctor. The implementation is based on OpenStack and related components. The
 Monitor can be realized by a sample Python-based implementation provided in the
 Doctor code repository. The Controller is realized by OpenStack Nova, Neutron
 and Cinder for compute, network and storage, respectively. The Inspector can be
 Monitor can be realized by a sample Python-based implementation provided in the
 Doctor code repository. The Controller is realized by OpenStack Nova, Neutron
 and Cinder for compute, network and storage, respectively. The Inspector can be

-realized by OpenStack Congress or a sample Python-based implementation also
+realized by OpenStack Congress, Vitrage or a sample Python-based implementation also

 available in the code repository of Doctor. The Notifier is realized by
 OpenStack Aodh.
 
 available in the code repository of Doctor. The Notifier is realized by
 OpenStack Aodh.
 


@@ -26,18 +26,21 @@ Immediate Notification
 Immediate notification can be used by creating 'event' type alarm via
 OpenStack Alarming (Aodh) API with relevant internal components support.
 
 Immediate notification can be used by creating 'event' type alarm via
 OpenStack Alarming (Aodh) API with relevant internal components support.
 

-See, upstream spec document:
-http://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html
+See:
+- Upstream spec document:
+https://specs.openstack.org/openstack/ceilometer-specs/specs/liberty/event-alarm-evaluator.html
+- Aodh official documentation:
+https://docs.openstack.org/aodh/latest

 
 An example of a consumer of this notification can be found in the Doctor
 repository. It can be executed as follows:
 
 .. code-block:: bash
 
 
 An example of a consumer of this notification can be found in the Doctor
 repository. It can be executed as follows:
 
 .. code-block:: bash
 

-    git clone https://gerrit.opnfv.org/gerrit/doctor -b stable/danube
-    cd doctor/tests
+    git clone https://gerrit.opnfv.org/gerrit/doctor
+    cd doctor/doctor_tests/consumer

     CONSUMER_PORT=12346
     CONSUMER_PORT=12346

-    python consumer.py "$CONSUMER_PORT" > consumer.log 2>&1 &
+    python sample.py "$CONSUMER_PORT" > consumer.log 2>&1 &

 
 Consistent resource state awareness
 -----------------------------------
 
 Consistent resource state awareness
 -----------------------------------


@@ -46,9 +49,10 @@ Resource state of compute host can be changed/updated according to a trigger
 from a monitor running outside of OpenStack Compute (Nova) by using
 force-down API.
 
 from a monitor running outside of OpenStack Compute (Nova) by using
 force-down API.
 

-See
-http://artifacts.opnfv.org/doctor/danube/manuals/mark-host-down_manual.html
-for more detail.
+See:
+* Upstream spec document: https://specs.openstack.org/openstack/nova-specs/specs/liberty/implemented/mark-host-down.html
+* Upstream Compute API reference document: https://developer.openstack.org/api-ref/compute
+* Doctor Mark Host Down Manual: https://git.opnfv.org/doctor/tree/docs/development/manuals/mark-host-down_manual.rst

 
 Valid compute host status given to VM owner
 -------------------------------------------
 
 Valid compute host status given to VM owner
 -------------------------------------------


@@ -56,6 +60,42 @@ Valid compute host status given to VM owner
 The resource state of a compute host can be retrieved by a user with the
 OpenStack Compute (Nova) servers API.
 
 The resource state of a compute host can be retrieved by a user with the
 OpenStack Compute (Nova) servers API.
 

-See
-http://artifacts.opnfv.org/doctor/danube/manuals/get-valid-server-state.html
-for more detail.
+See:
+* Upstream spec document: https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/get-valid-server-state.html
+* Upstream Compute API reference document: https://developer.openstack.org/api-ref/compute
+* Doctor Get Valid Server State Manual: https://git.opnfv.org/doctor/tree/docs/development/manuals/get-valid-server-state.rst
+
+Port data plane status update
+-----------------------------
+
+Port data plane status can be changed/updated in the case of issues in the underlying data plane
+affecting connectivity from/to Neutron ports.
+
+See:
+* Upstream spec document: https://specs.openstack.org/openstack/neutron-specs/specs/pike/port-data-plane-status.html
+* Upstream Networking API reference document: https://developer.openstack.org/api-ref/network
+
+Doctor driver (Congress)
+------------------------
+
+The Doctor driver can be notified about NFVI failures that have been detected by monitoring systems.
+
+See:
+* Upstream spec document: https://specs.openstack.org/openstack/congress-specs/specs/mitaka/push-type-datasource-driver.html
+* Congress official documentation: https://docs.openstack.org/congress/latest
+
+Event API (Vitrage)
+-------------------
+With this API, monitoring systems can push events to the Doctor datasource.
+
+See:
+* Upstream spec document: https://specs.openstack.org/openstack/vitrage-specs/specs/ocata/event-api.html
+* Vitrage official documentation: https://docs.openstack.org/vitrage/latest
+
+Doctor datasource (Vitrage)
+---------------------------
+After receiving events from monitoring systems, the Doctor datasource identifies the affected resources based on the resource topology.
+
+See:
+* Upstream spec document: https://specs.openstack.org/openstack/vitrage-specs/specs/ocata/doctor-datasource.html
+