docs/design/2A1-Appendix.rst

   1 ========
   2 Appendix
   3 ========
   4
   5 A.1 Impact Analysis
   6 ===================
   7
   8 Upgrading the different software modules may cause different impact on
   9 the availability of the infrastructure resources and even on the service
  10 continuity of the vNFs.
  11
  12 **Software modules in the computing nodes**
  13
  14 #. Host OS patch
  15
  16 #. Hypervisor, such as KVM, QEMU, XEN, libvirt
  17 #. Openstack agent in computing nodes (like Nova agent, Ceilometer
  18    agent...)
  19
  20 .. <MT> As SW module, we should list the host OS and maybe its
  21    drivers as well. From upgrade perspective do we limit host OS
  22    upgrades to patches only?
  23
  24 **Software modules in network nodes**
  25
  26 #. Neutron L2/L3 agent
  27 #. OVS, SR-IOV Driver
  28
  29 **Software modules storage nodes**
  30
  31 #. Ceph
  32
  33 The table below analyses such an impact - considering a single instance
  34 of each software module - from the following aspects:
  35
  36 -  the function which will be lost during upgrade,
  37 -  the duration of the loss of this specific function,
  38 -  if this causes the loss of the vNF function,
  39 -  if it causes incompatibility in the different parts of the software,
  40 -  what should be backed up before the upgrade,
  41 -  the duration of restoration time if the upgrade fails
  42
  43 These values provided come from internal testing and based on some
  44 assumptions, they may vary depending on the deployment techniques.
  45 Please feel free to add if you find more efficient values during your
  46 testing.
  47
  48 https://wiki.opnfv.org/_media/upgrade_analysis_v0.5.xlsx
  49
  50 Note that no redundancy of the software modules is considered in the table.