summaryrefslogtreecommitdiffstats
path: root/docs/requirements/05-implementation.rst
diff options
context:
space:
mode:
authorBertrand Souville <souville@docomolab-euro.com>2016-02-03 11:50:26 +0100
committerGerald Kunzmann <kunzmann@docomolab-euro.com>2016-02-03 15:33:24 +0000
commitb45cc33e329fd978f0fd448eec39f8f7b37af770 (patch)
tree7952e360334671f0fb034480551976d2c09eaa7b /docs/requirements/05-implementation.rst
parente036d0f69b14dcbe0711c1e46448f380912d794f (diff)
Editorial changes in Section 5.2.2 NFVI Maintenance
JIRA: DOCTOR-14 Change-Id: If10dc1c00c674e26bb6fe6cf96efe2b70885748c Signed-off-by: Bertrand Souville <souville@docomolab-euro.com> (cherry picked from commit ff89aac08658fce4b8eb0b6cc98eccac4fc3670e)
Diffstat (limited to 'docs/requirements/05-implementation.rst')
-rw-r--r--docs/requirements/05-implementation.rst33
1 files changed, 15 insertions, 18 deletions
diff --git a/docs/requirements/05-implementation.rst b/docs/requirements/05-implementation.rst
index 1f1b4a74..6790d2f0 100644
--- a/docs/requirements/05-implementation.rst
+++ b/docs/requirements/05-implementation.rst
@@ -118,10 +118,9 @@ The detailed work flow for fault management is as follows (see also :numref:`fig
affected resources, for example migrate/update/terminate specific
resource(s). After reception of such instructions, the VIM is executing the
requested action, e.g. it will migrate or terminate a virtual resource.
-
- a. Query request from Consumer to VIM to get information about the current
+a. Query request from Consumer to VIM to get information about the current
status of a resource.
- b. Response to the query request with information about the current status of
+b. Response to the query request with information about the current status of
the queried resource. In case the resource is in "fault" state, information
about the related fault(s) is returned.
@@ -164,6 +163,11 @@ the 4 building blocks introduced in :ref:`impl_fb`.
NFVI Maintenance
^^^^^^^^^^^^^^^^
+.. figure:: images/figure9.png
+ :name: figure9
+ :width: 100%
+
+ NFVI maintenance work flow
The detailed work flow for NFVI maintenance is shown in :numref:`figure9`
and has the following steps. Note that steps 1, 2, and 5 to 8a in the NFVI
@@ -180,25 +184,18 @@ flow and share a similar implementation plan in Release 1.
6. Maintenance notification to Consumer.
7. The Consumer switches to standby configuration (STBY)
8. Instructions from Consumer to VIM requesting certain recovery actions to be
- performed (step 7a). After reception of such instructions, the VIM is
+ performed (step 8a). After reception of such instructions, the VIM is
executing the requested action in order to empty the physical resources (step
- 7b).
+ 8b).
9. Maintenance response from VIM to inform the Administrator that the physical
machines have been emptied (or the operation resulted in an error state).
10. Administrator is coordinating and executing the maintenance operation/work
on the NFVI.
-
- A) Query request from Administrator to VIM to get information about the
- current state of a resource.
- B) Response to the query request with information about the current state of
- the queried resource(s). In case the resource is in "maintenance" state,
- information about the related maintenance operation is returned.
-
-.. figure:: images/figure9.png
- :name: figure9
- :width: 100%
-
- NFVI maintenance work flow
+a) Query request from Administrator to VIM to get information about the
+ current state of a resource.
+b) Response to the query request with information about the current state of
+ the queried resource(s). In case the resource is in "maintenance" state,
+ information about the related maintenance operation is returned.
.. figure:: images/figure10.png
:name: figure10
@@ -206,7 +203,7 @@ flow and share a similar implementation plan in Release 1.
NFVI Maintenance implementation plan
-:numref:`figure10` shows a more detailed message flow (Steps 4 to 6)
+:numref:`figure10` shows a more detailed message flow (Steps 3 to 6 and 9)
between the 4 building blocks introduced in Section 5.1..
3. The Administrator is sending a StateChange request to the Controller residing