docs/release/scenarios/fault_management/fault_management.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3
   4
   5 Running test cases
   6 """"""""""""""""""
   7
   8 Functest will call the "doctor_tests/main.py" in Doctor to run the test job.
   9 Doctor testing can also be triggered by tox on OPNFV installer jumphost. Tox
  10 is normally used for functional, module and coding style testing in Python
  11 project.
  12
  13 Currently 'MCP' and 'devstack' installer are supported.
  14
  15
  16 Fault management use case
  17 """""""""""""""""""""""""
  18
  19 * A consumer of the NFVI wants to receive immediate notifications about faults
  20   in the NFVI affecting the proper functioning of the virtual resources.
  21   Therefore, such faults have to be detected as quickly as possible, and, when
  22   a critical error is observed, the affected consumer is immediately informed
  23   about the fault and can switch over to the STBY configuration.
  24
  25 The faults to be monitored (and at which detection rate) will be configured by
  26 the consumer. Once a fault is detected, the Inspector in the Doctor
  27 architecture will check the resource map maintained by the Controller, to find
  28 out which virtual resources are affected and then update the resources state.
  29 The Notifier will receive the failure event requests sent from the Controller,
  30 and notify the consumer(s) of the affected resources according to the alarm
  31 configuration.
  32
  33 Detailed workflow information is as follows:
  34
  35 * Consumer(VNFM): (step 0) creates resources (network, server/instance) and an
  36   event alarm on state down notification of that server/instance or Neutron
  37   port.
  38
  39 * Monitor: (step 1) periodically checks nodes, such as ping from/to each
  40   dplane nic to/from gw of node, (step 2) once it fails to send out event
  41   with "raw" fault event information to Inspector
  42
  43 * Inspector: when it receives an event, it will (step 3) mark the host down
  44   ("mark-host-down"), (step 4) map the PM to VM, and change the VM status to
  45   down. In network failure case, also Neutron port is changed to down.
  46
  47 * Controller: (step 5) sends out instance update event to Ceilometer. In network
  48   failure case, also Neutron port is changed to down and corresponding event is
  49   sent to Ceilometer.
  50
  51 * Notifier: (step 6) Ceilometer transforms and passes the events to AODH,
  52   (step 7) AODH will evaluate events with the registered alarm definitions,
  53   then (step 8) it will fire the alarm to the "consumer" who owns the
  54   instance
  55
  56 * Consumer(VNFM): (step 9) receives the event and (step 10) recreates a new
  57   instance
  58
  59 Fault management test case
  60 """"""""""""""""""""""""""
  61
  62 Functest will call the 'doctor-test' command in Doctor to run the test job.
  63
  64 The following steps are executed:
  65
  66 Firstly, get the installer ip according to the installer type. Then ssh to
  67 the installer node to get the private key for accessing to the cloud. As
  68 'fuel' installer, ssh to the controller node to modify nova and ceilometer
  69 configurations.
  70
  71 Secondly, prepare image for booting VM, then create a test project and test
  72 user (both default to doctor) for the Doctor tests.
  73
  74 Thirdly, boot a VM under the doctor project and check the VM status to verify
  75 that the VM is launched completely. Then get the compute host info where the VM
  76 is launched to verify connectivity to the target compute host. Get the consumer
  77 ip according to the route to compute ip and create an alarm event in Ceilometer
  78 using the consumer ip.
  79
  80 Fourthly, the Doctor components are started, and, based on the above preparation,
  81 a failure is injected to the system, i.e. the network of compute host is
  82 disabled for 3 minutes. To ensure the host is down, the status of the host
  83 will be checked.
  84
  85 Finally, the notification time, i.e. the time between the execution of step 2
  86 (Monitor detects failure) and step 9 (Consumer receives failure notification)
  87 is calculated.
  88
  89 According to the Doctor requirements, the Doctor test is successful if the
  90 notification time is below 1 second.