diff options
author | Jie Hu <hu.jie@zte.com.cn> | 2015-12-16 18:52:19 +0800 |
---|---|---|
committer | Jie Hu <hu.jie@zte.com.cn> | 2015-12-16 19:11:03 +0800 |
commit | 61a851845546300cc2f5ee9f3dd6761c9ecd093e (patch) | |
tree | 55951df60665c7950ea4b82e0a503a422eec2f5c /docs/requirements/300-Gap_Analysis_Report.rst | |
parent | 0fdf3b89887dfb7a9ea303f58c5e06c348889aa0 (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/requirements/300-Gap_Analysis_Report.rst')
-rw-r--r-- | docs/requirements/300-Gap_Analysis_Report.rst | 50 |
1 files changed, 50 insertions, 0 deletions
diff --git a/docs/requirements/300-Gap_Analysis_Report.rst b/docs/requirements/300-Gap_Analysis_Report.rst new file mode 100644 index 0000000..1f1d3fe --- /dev/null +++ b/docs/requirements/300-Gap_Analysis_Report.rst @@ -0,0 +1,50 @@ +=================== +Gap Analysis Report +=================== + +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. |