Merge "Replace chapter name by reST reference labels"
authorRyota MIBU <r-mibu@cq.jp.nec.com>
Mon, 6 Jul 2015 09:31:06 +0000 (09:31 +0000)
committerGerrit Code Review <gerrit@172.30.200.206>
Mon, 6 Jul 2015 09:31:06 +0000 (09:31 +0000)
design_docs/README
requirements/03-architecture.rst
requirements/index.rst

index 52f31ff..f0491cf 100644 (file)
@@ -1,9 +1,9 @@
-This is directory to store design documents which may includes draft version
-of blueprints written before proposing upstream OSS communities such as
-OpenStack, in order to keep the original blueprint as reviewed in OPNFV.
-That means there could be out-of-dated blueprints as result of further
-refinements in the upstream OSS coummunity. So please refer the link in each
-document to find current version of blueprint and status of development in the
-relevant OSS community.
+This is the directory to store design documents which may include draft
+versions of blueprints written before proposing to upstream OSS communities
+such as OpenStack, in order to keep the original blueprint as reviewed in
+OPNFV. That means there could be out-dated blueprints as result of further
+refinements in the upstream OSS community. Please refer to the link in each
+document to find the latest version of the blueprint and status of development
+in the relevant OSS community.
 
 See also https://wiki.opnfv.org/requirements_projects .
index 2c2eea6..82a13f0 100644 (file)
@@ -69,12 +69,13 @@ General Features and Requirements
 The following features are required for the VIM to achieve high availability of
 applications (e.g., MME, S/P-GW) and the Network Services:
 
-* Monitoring: Monitor physical and virtual resources.
-* Detection: Detect unavailability of physical resources.
-* Correlation and Cognition: Correlate faults and identify affected virtual
-  resources.
-* Notification: Notify unavailable virtual resources to their Consumer(s).
-* Recovery action: Execute actions to process fault recovery and maintenance.
+1. Monitoring: Monitor physical and virtual resources.
+2. Detection: Detect unavailability of physical resources.
+3. Correlation and Cognition: Correlate faults and identify affected virtual
+   resources.
+4. Notification: Notify unavailable virtual resources to their Consumer(s).
+5. Fencing: Shut down or isolate a faulty resource
+6. Recovery action: Execute actions to process fault recovery and maintenance.
 
 The time interval between the instant that an event is detected by the
 monitoring system and the Consumer notification of unavailable resources shall
@@ -167,6 +168,20 @@ notifications is important. For example, the receiver function in the
 consumer-side implementation could have different schema, location, and policies
 (e.g. receive or not, aggregate events with the same cause, etc.).
 
+.. _fencing:
+
+Fencing
+^^^^^^^
+Recovery actions, e.g. safe VM evacuation, have to be preceded by fencing the
+failed host. Fencing hereby means to isolate or shut down a faulty resource.
+Without fencing -- when the perceived disconnection is due to some transient
+or partial failure -- the evacuation might lead into two identical instances
+running together and having a dangerous conflict.
+
+There is a cross-project effort in OpenStack ongoing to implement fencing. A
+general description of fencing in OpenStack is available here:
+https://wiki.openstack.org/wiki/Fencing_Instances_of_an_Unreachable_Host .
+
 Recovery Action
 ^^^^^^^^^^^^^^^
 
@@ -174,7 +189,7 @@ In the basic :ref:`uc-fault1` use case, no automatic actions will be taken by
 the VIM, but all recovery actions executed by the VIM and the NFVI will be
 instructed and coordinated by the Consumer.
 
-In a more advanced use case, the VIM shall be able to recover the failed virtual 
+In a more advanced use case, the VIM shall be able to recover the failed virtual
 resources according to a pre-defined behavior for that resource. In principle
 this means that the owner of the resource (i.e., its consumer or administrator)
 can define which recovery actions shall be taken by the VIM. Examples are a
index f280a63..8495365 100644 (file)
@@ -15,8 +15,6 @@ Doctor: Fault Management and Maintenance
 :Editors: Ashiq Khan (NTT DOCOMO), Gerald Kunzmann (NTT DOCOMO)
 :Authors: Ryota Mibu (NEC), Carlos Goncalves (NEC), Tomi Juvonen (Nokia),
           Tommy Lindgren (Ericsson)
-:Project creation date: 2014-12-02
-:Submission date: 2015-03-XX
 
 :Abstract: Doctor is an OPNFV requirement project [DOCT]_. Its scope is NFVI
            fault management, and maintenance and it aims at developing and
@@ -33,6 +31,16 @@ Doctor: Fault Management and Maintenance
            realization for a NFVI fault management and maintenance solution in
            open source software.
 
+:History:
+
+          ========== =====================================================
+          Date       Description
+          ========== =====================================================
+          02.12.2014 Project creation
+          14.04.2015 Initial version of the deliverable uploaded to Gerrit
+          18.05.2015 Stable version of the Doctor deliverable
+          ========== =====================================================
+
 
 .. raw:: latex