summaryrefslogtreecommitdiffstats
path: root/docs/design/2A1-Appendix.rst
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/2A1-Appendix.rst
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/2A1-Appendix.rst')
-rw-r--r--docs/design/2A1-Appendix.rst50
1 files changed, 50 insertions, 0 deletions
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.