|author||Jie Hu <firstname.lastname@example.org>||2015-12-16 18:52:19 +0800|
|committer||Jie Hu <email@example.com>||2015-12-16 19:11:03 +0800|
diff --git a/docs/requirements/300-Gap_Analysis_Report.rst b/docs/requirements/300-Gap_Analysis_Report.rst
new file mode 100644
@@ -0,0 +1,50 @@
+Gap Analysis Report
+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
+.. <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**
+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
+Note that no redundancy of the software modules is considered in the table.