summaryrefslogtreecommitdiffstats
path: root/docs/design
diff options
context:
space:
mode:
authorJie Hu <hu.jie@zte.com.cn>2015-12-16 18:52:19 +0800
committerJie Hu <hu.jie@zte.com.cn>2015-12-16 19:11:03 +0800
commit61a851845546300cc2f5ee9f3dd6761c9ecd093e (patch)
tree55951df60665c7950ea4b82e0a503a422eec2f5c /docs/design
parent0fdf3b89887dfb7a9ea303f58c5e06c348889aa0 (diff)
ESCALATOR-31 Adjusting documentationbrahmaputra.1.0stable/brahmaputra
JIRA: ESCALATOR-31 Change-Id: I0b83511a542982f07c2ab9d60517f4b5f357569b Signed-off-by: Jie Hu <hu.jie@zte.com.cn>
Diffstat (limited to 'docs/design')
-rw-r--r--docs/design/201-Reference_Architecture.rst54
-rw-r--r--docs/design/202-Information_Flows.rst57
-rw-r--r--docs/design/203-Administrative_Interfaces.rst16
-rw-r--r--docs/design/204-Configuration_and_Logging.rst18
-rw-r--r--docs/design/2A1-Appendix.rst50
-rw-r--r--docs/design/etc/conf.py34
-rw-r--r--docs/design/etc/opnfv-logo.pngbin0 -> 2829 bytes
-rw-r--r--docs/design/images/figure2.pngbin0 -> 9196 bytes
-rw-r--r--docs/design/images/figure3.pngbin0 -> 25188 bytes
-rw-r--r--docs/design/images/figure4.pngbin0 -> 122040 bytes
-rw-r--r--docs/design/images/figure5.pngbin0 -> 28490 bytes
-rw-r--r--docs/design/images/figure6.pngbin0 -> 46314 bytes
-rw-r--r--docs/design/index.rst33
13 files changed, 262 insertions, 0 deletions
diff --git a/docs/design/201-Reference_Architecture.rst b/docs/design/201-Reference_Architecture.rst
new file mode 100644
index 0000000..75aa461
--- /dev/null
+++ b/docs/design/201-Reference_Architecture.rst
@@ -0,0 +1,54 @@
+======================
+Reference Architecture
+======================
+
+This section describes the reference architecture, the function blocks,
+and the function entities of Escalator for the reader to well understand how
+the basic functions to be organized.
+
+The software stack on each node is generally as shown in the table below.
+
+.. figure:: images/figure2.png
+ :name: figure2
+ :width: 100%
+
+Since the upgrading of control node will not affect the VNFs service in the blue
+box, this chapter will focusing on the upgrading of compute nodes.
+
+
+Precondition of Upgrade
+=======================
+
+Upgrade related modules in VIM
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Upgrade operations are initiated by the user through the VIM. For VIM, upgrade
+management mainly contains the object:
+
+- **Upgrade Manager**
+
+Mainly responsible for control of the upgrade process.The Escalator is required
+to know the software deployment information of the platform and will use these
+information during the upgrading. It will be collected from some place, such
+as the Installer, Deploy Manager and Escalator itself, etc.
+
+- **VIM Interface**:
+
+Mainly responsible for the external interface, include Vi-Vnfm, Or-Vi. This
+module stores VNFO and VNFM external information such as address and
+authentication.
+
+- **Cloud Manager**:
+
+Mainly responsible for virtualization resources management,which might be
+considered made up of Openstack and SDN control node.
+
+- **System Support**:
+
+This layer is the runtime support environment of upper layers, e.g. Cloud
+Manager and VIM interface., including:OS, HA, etc. To upgrade the upper
+software is based on this module.
+
+.. figure:: images/figure3.png
+ :name: figure3
+ :width: 100%
diff --git a/docs/design/202-Information_Flows.rst b/docs/design/202-Information_Flows.rst
new file mode 100644
index 0000000..eaa39f0
--- /dev/null
+++ b/docs/design/202-Information_Flows.rst
@@ -0,0 +1,57 @@
+=================
+Information Flows
+=================
+
+This section describes the information flows among the function
+entities when Escalator is in actions.
+
+1. Upgrade process of Compute nodes
+
+1.1 consider VIM as a whole
+
+.. figure:: images/figure4.png
+ :name: figure4
+ :width: 100%
+
+process is:
+1. Operators add new version files on the VIM,initiate the upgrade.
+2. VIM chooses some compute nodes as the upgrade target nodes, and set them
+into maintenance mode. VIM queries the list of running VMs on target nodes.
+3. VIM notice VNFM corresponding to the virtual machine, to migrate the
+business.
+4. VNFM migrates the business. If the business is in active of active-standby
+mode, it will initiate switch-over. If the business is in loading balance mode,
+it will move the business to other node.
+5. After VNFM moves business, it notifies the VIM.
+6. VIM judges whether the business on the target VM has all been moved. If
+not, VIM migrates the VM with business loaded to other free nodes. Then VIM
+upgrades the target computer nodes. After upgrade, VIM set the target compute
+nodes into normal nodes.
+7. If there are computer nodes remained to be upgraded, goto step 2.
+
+4.2 from inside VIM
+
+.. figure:: images/figure5.png
+ :name: figure5
+ :width: 100%
+
+.. figure:: images/figure6.png
+ :name: figure6
+ :width: 100%
+
+process is:
+1. Upgrade manager receives user operation commands. Add new version files.
+Upgrade is began.
+2. Upgrade Manager selects compute node A to Upgrade. Query list of the VMs
+running the compute nodes A to the Cloud Manager, and set the node to
+maintenance mode, that is to say creation or migration of new VM on this node
+is impossible anymore.
+3. Upgrade Manager notifies VNFM compute node A into maintenance mode by VIM
+interface, temporarily disabling the inserting of business, and business on
+compute node A need move to the other available compute nodes.
+4. When receives the VNFM reply, or waited for a timeout, Upgrade Manager
+notifies the system support on compute node A to do software upgrade.
+5. After upgraded, Upgrade Manager removes maintenance mode for the compute
+node A.
+6. Upgrade Manager claims VNFM computing nodes A available.
+7. Select computer node B to upgrade
diff --git a/docs/design/203-Administrative_Interfaces.rst b/docs/design/203-Administrative_Interfaces.rst
new file mode 100644
index 0000000..5d8148b
--- /dev/null
+++ b/docs/design/203-Administrative_Interfaces.rst
@@ -0,0 +1,16 @@
+=========================
+Administrative Interfaces
+=========================
+
+This section describes the required administrative interfaces of Escalator.
+
+CLI Interface
+=============
+
+This section describes CLI of Escalator.
+
+RESTful API
+===========
+
+This section describes the API of Escalator for developer.
+
diff --git a/docs/design/204-Configuration_and_Logging.rst b/docs/design/204-Configuration_and_Logging.rst
new file mode 100644
index 0000000..309b2c8
--- /dev/null
+++ b/docs/design/204-Configuration_and_Logging.rst
@@ -0,0 +1,18 @@
+=========================
+Configuration and Logging
+=========================
+
+This section describes the required configuration and logging of Escalator.
+
+
+Configuration Format
+====================
+
+This section will suggest a format of the configuration files and how to
+deal with it.
+
+Logging Format
+==============
+
+This section will suggest a format of the log files and how to deal with
+it.
diff --git a/docs/design/2A1-Appendix.rst b/docs/design/2A1-Appendix.rst
new file mode 100644
index 0000000..80fe447
--- /dev/null
+++ b/docs/design/2A1-Appendix.rst
@@ -0,0 +1,50 @@
+========
+Appendix
+========
+
+A.1 Impact Analysis
+===================
+
+Upgrading the different software modules may cause different impact on
+the availability of the infrastructure resources and even on the service
+continuity of the vNFs.
+
+**Software modules in the computing nodes**
+
+#. Host OS patch
+
+#. Hypervisor, such as KVM, QEMU, XEN, libvirt
+#. Openstack agent in computing nodes (like Nova agent, Ceilometer
+ agent...)
+
+.. <MT> As SW module, we should list the host OS and maybe its
+ drivers as well. From upgrade perspective do we limit host OS
+ upgrades to patches only?
+
+**Software modules in network nodes**
+
+#. Neutron L2/L3 agent
+#. OVS, SR-IOV Driver
+
+**Software modules storage nodes**
+
+#. Ceph
+
+The table below analyses such an impact - considering a single instance
+of each software module - from the following aspects:
+
+- the function which will be lost during upgrade,
+- the duration of the loss of this specific function,
+- if this causes the loss of the vNF function,
+- if it causes incompatibility in the different parts of the software,
+- what should be backed up before the upgrade,
+- the duration of restoration time if the upgrade fails
+
+These values provided come from internal testing and based on some
+assumptions, they may vary depending on the deployment techniques.
+Please feel free to add if you find more efficient values during your
+testing.
+
+https://wiki.opnfv.org/_media/upgrade_analysis_v0.5.xlsx
+
+Note that no redundancy of the software modules is considered in the table.
diff --git a/docs/design/etc/conf.py b/docs/design/etc/conf.py
new file mode 100644
index 0000000..0066035
--- /dev/null
+++ b/docs/design/etc/conf.py
@@ -0,0 +1,34 @@
+import datetime
+import sys
+import os
+
+try:
+ __import__('imp').find_module('sphinx.ext.numfig')
+ extensions = ['sphinx.ext.numfig']
+except ImportError:
+ # 'pip install sphinx_numfig'
+ extensions = ['sphinx_numfig']
+
+# numfig:
+number_figures = True
+figure_caption_prefix = "Fig."
+
+source_suffix = '.rst'
+master_doc = 'index'
+pygments_style = 'sphinx'
+html_use_index = False
+
+pdf_documents = [('index', u'OPNFV', u'OPNFV Project', u'OPNFV')]
+pdf_fit_mode = "shrink"
+pdf_stylesheets = ['sphinx','kerning','a4']
+#latex_domain_indices = False
+#latex_use_modindex = False
+
+latex_elements = {
+ 'printindex': '',
+}
+
+project = u'OPNFV: Template documentation config'
+copyright = u'%s, OPNFV' % datetime.date.today().year
+version = u'1.0.0'
+release = u'1.0.0'
diff --git a/docs/design/etc/opnfv-logo.png b/docs/design/etc/opnfv-logo.png
new file mode 100644
index 0000000..1519503
--- /dev/null
+++ b/docs/design/etc/opnfv-logo.png
Binary files differ
diff --git a/docs/design/images/figure2.png b/docs/design/images/figure2.png
new file mode 100644
index 0000000..70d16c7
--- /dev/null
+++ b/docs/design/images/figure2.png
Binary files differ
diff --git a/docs/design/images/figure3.png b/docs/design/images/figure3.png
new file mode 100644
index 0000000..38346de
--- /dev/null
+++ b/docs/design/images/figure3.png
Binary files differ
diff --git a/docs/design/images/figure4.png b/docs/design/images/figure4.png
new file mode 100644
index 0000000..e74e24b
--- /dev/null
+++ b/docs/design/images/figure4.png
Binary files differ
diff --git a/docs/design/images/figure5.png b/docs/design/images/figure5.png
new file mode 100644
index 0000000..a49955d
--- /dev/null
+++ b/docs/design/images/figure5.png
Binary files differ
diff --git a/docs/design/images/figure6.png b/docs/design/images/figure6.png
new file mode 100644
index 0000000..efe7d6f
--- /dev/null
+++ b/docs/design/images/figure6.png
Binary files differ
diff --git a/docs/design/index.rst b/docs/design/index.rst
new file mode 100644
index 0000000..993b5e6
--- /dev/null
+++ b/docs/design/index.rst
@@ -0,0 +1,33 @@
+.. OPNFV Release Engineering documentation, created by
+ sphinx-quickstart on Tue Jun 9 19:12:31 2015.
+ You can adapt this file completely to your liking, but it should at least
+ contain the root `toctree` directive.
+
+.. image:: etc/opnfv-logo.png
+ :height: 40
+ :width: 200
+ :alt: OPNFV
+ :align: left
+
+ESCALATOR DESIGN CONSIDERATIONS
+=======================================
+
+Contents:
+
+.. toctree::
+ :maxdepth: 4
+ :titlesonly:
+
+
+
+ 201-Reference_Architecture.rst
+ 202-Information_Flows.rst
+ 203-Administrative_Interfaces.rst
+ 204-Configuration_and_Logging.rst
+ 300-Gap_Analysis_Report.rst
+
+* :ref:`search`
+
+Revision: _sha1_
+
+Build date: |today|