summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/platformoverview/doctor.rst47
-rwxr-xr-xdocs/platformoverview/images/figure-p1.pngbin0 -> 60756 bytes
-rw-r--r--docs/platformoverview/index.rst9
-rw-r--r--docs/requirements/05-implementation.rst14
-rw-r--r--docs/userguide/userguide.rst7
5 files changed, 72 insertions, 5 deletions
diff --git a/docs/platformoverview/doctor.rst b/docs/platformoverview/doctor.rst
new file mode 100644
index 00000000..6ee59a9f
--- /dev/null
+++ b/docs/platformoverview/doctor.rst
@@ -0,0 +1,47 @@
+===============
+Doctor Platform
+===============
+
+https://wiki.opnfv.org/doctor
+
+Features
+========
+
+Doctor platform, as of Brahmaputra release, provides the two features:
+
+* Immediate Notification
+* Consistent resource state awareness (Compute)
+
+These features enable high availability of Network Services on top of
+the virtualized infrastructure. Immediate notification allows VNF managers
+(VNFM) to process recovery actions promptly once a failure has occurred.
+Consistency of resource state is necessary to properly execute recovery
+actions properly in the VIM.
+
+Components
+==========
+
+Doctor platform, as of Brahmaputra release, consists of the following
+components:
+
+* OpenStack Compute (Nova)
+* OpenStack Telemetry (Ceilometer)
+* OpenStack Alarming (Aodh)
+* Doctor Inspector
+* Doctor Monitor
+
+.. note::
+ Doctor Inspector and Monitor are sample implementation for reference.
+
+You can see an overview of the Doctor platform and how components interact in
+:numref:`figure-p1`.
+
+.. figure:: images/figure-p1.png
+ :name: figure-p1
+ :width: 100%
+
+ Doctor platform and typical sequence (Brahmaputra)
+
+Detailed information on the Doctor architecture can be found in the Doctor
+requirements documentation:
+http://artifacts.opnfv.org/doctor/docs/requirements/05-implementation.html
diff --git a/docs/platformoverview/images/figure-p1.png b/docs/platformoverview/images/figure-p1.png
new file mode 100755
index 00000000..e963d8bd
--- /dev/null
+++ b/docs/platformoverview/images/figure-p1.png
Binary files differ
diff --git a/docs/platformoverview/index.rst b/docs/platformoverview/index.rst
new file mode 100644
index 00000000..cee06eb3
--- /dev/null
+++ b/docs/platformoverview/index.rst
@@ -0,0 +1,9 @@
+***************************
+Overview of Doctor Platform
+***************************
+
+.. toctree::
+ :numbered:
+ :maxdepth: 2
+
+ doctor.rst
diff --git a/docs/requirements/05-implementation.rst b/docs/requirements/05-implementation.rst
index e7f35158..1f1b4a74 100644
--- a/docs/requirements/05-implementation.rst
+++ b/docs/requirements/05-implementation.rst
@@ -296,7 +296,9 @@ described in the previous section applies. In addition, the Controller(s) will
take appropriate actions to evacuate the physical machines in order to prepare
them for the planned maintenance operation. After the physical machines are
emptied, the Controller will inform the Administrator that it can initiate the
-maintenance.
+maintenance. Alternatively the VMs can just be shut down and boot up on the
+same host after maintenance is over. There needs to be policy for administrator
+to know the plan for VMs in maintenance.
Information elements
--------------------
@@ -492,10 +494,12 @@ After reception of this request, the Consumer will decide on the optimal
action to resolve the fault. This includes actions like switching to a hot
standby virtual resource, migration of the fault virtual resource to another
physical machine, termination of the faulty virtual resource and instantiation
-of a new virtual resource in order to provide a new hot standby resource.
-Existing resource management interfaces and messages between the Consumer and
-the VIM can be used for those actions, and there is no need to define additional
-actions on the Fault Management Interface.
+of a new virtual resource in order to provide a new hot standby resource. In
+some use cases the Consumer can leave virtual resources on failed host to be
+booted up again after fault is recovered. Existing resource management
+interfaces and messages between the Consumer and the VIM can be used for those
+actions, and there is no need to define additional actions on the Fault
+Management Interface.
Parameters:
diff --git a/docs/userguide/userguide.rst b/docs/userguide/userguide.rst
new file mode 100644
index 00000000..7f3e4f90
--- /dev/null
+++ b/docs/userguide/userguide.rst
@@ -0,0 +1,7 @@
+<Feature> capabilities and usage
+================================
+Describe the specific capabilities and usage for <XYZ> feature.
+
+<Feature and API usage guidelines and example>
+-----------------------------------------------
+Describe with examples how to use specfic features.