Replace word 'poison' by 'force'

[doctor.git] / requirements / 05-implementation.rst

diff --git a/requirements/05-implementation.rst b/requirements/05-implementation.rst
index a4048df..e624a99 100644 (file)
--- a/requirements/05-implementation.rst
+++ b/requirements/05-implementation.rst
@@ -12,6 +12,8 @@ the related northbound interface and the related information elements. Finally,
 Section 5.6 provides a first set of blueprints to address selected gaps required
 for the realization functionalities of the Doctor project.
 
+.. _impl_fb:
+
 Functional Blocks
 -----------------
 
@@ -58,10 +60,11 @@ The Controller is responsible for maintaining the resource map (i.e. the mapping
 from physical resources to virtual resources), accepting update requests for the
 resource state(s) (exposing as provider API), and sending all failure events
 regarding virtual resources to the Notifier. Optionally, the Controller has the
-ability to poison the state of virtual resources mapping to physical resources
-for which it has received failure notifications from the Inspector. The
-Controller also re-calculates the capacity of the NVFI when receiving a failure
-notification for a physical resource.
+ability to force the state of a given physical resource to down in the resource
+mapping when it receives failure notifications from the Inspector for that
+given physical resource.
+The Controller also re-calculates the capacity of the NVFI when receiving a
+failure notification for a physical resource.
 
 In a real-world deployment, the VIM may have several controllers, one for each
 resource type, such as Nova, Neutron and Cinder in OpenStack. Each controller
@@ -88,7 +91,7 @@ to users with relevant ownership, whereas the latter is related to raw devices
 or small entities which should be handled with an administrator privilege.
 
 The northbound interface between the Notifier and the Consumer/Administrator is
-specified in Section 5.5.
+specified in :ref:`impl_nbi`.
 
 Sequence
 --------
@@ -144,7 +147,7 @@ shall be less than 1 second.
    Fault management scenario
 
 :num:`Figure #figure8` shows a more detailed message flow (Steps 4 to 6) between
-the 4 building blocks introduced in Section 5.1.
+the 4 building blocks introduced in :ref:`impl_fb`.
 
 4. The Monitor observed a fault in the NFVI and reports the raw fault to the
    Inspector.
@@ -428,6 +431,8 @@ and :num:`Figure #figure14`):
   - PhysicalResourceState [1] (String)
   - ZoneID [0..1] (Identifier)
 
+.. _impl_nbi:
+
 Detailed northbound interface specification
 -------------------------------------------