summaryrefslogtreecommitdiffstats
path: root/testcases/config_functest.yaml
blob: c38b460665fa36ed322675e3d28e44225beb16e1 (plain) 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

---
general:
    directories:
        # Relative to the path where the repo is cloned:
        dir_vping:      testcases/vPing/CI/libraries/
        dir_odl:        testcases/Controllers/ODL/CI/
        dir_rally:      testcases/VIM/OpenStack/CI/libraries/
        dir_rally_scn:  testcases/VIM/OpenStack/CI/suites/
        # Relative to $HOME:
        dir_rally_res:  functest/results/ # $HOME/functest/results
        dir_rally_repo: functest/Rally_repo/ # $HOME/Rally_repo/
        dir_rally_inst: .rally/  # $HOME/.rally/ usually

    openstack:
        image_name: functest-img
        image_url:  http://download.cirros-cloud.net/0.3.4/cirros-0.3.4-x86_64-disk.img
        image_disk_format:  qcow2
        image_download_path:    functest/ # $HOME/functest/
        #Public network. Optional
        neutron_public_net_name: net04_ext
        neutron_public_subnet_name: net04_ext__subnet
        neutron_public_subnet_cidr: 172.16.9.0/24
        neutron_public_subnet_start: 172.16.9.130
        neutron_public_subnet_end: 172.16.9.254
        #Private network for functest. Will be created by config_functest.py
        neutron_private_net_name: functest-net
        neutron_private_subnet_name: functest-subnet
        neutron_private_subnet_cidr: 192.168.120.0/24
        neutron_private_subnet_start: 192.168.120.2
        neutron_private_subnet_end: 192.168.120.254
        neutron_private_subnet_gateway: 192.168.120.254
        neutron_router_name: functest-router
vping:
    ping_timeout:   200
    vm_flavor: m1.small #adapt to your environment
    vm_name_1: opnfv-vping-1
    vm_name_2: opnfv-vping-2
    ip_1: 192.168.120.30
    ip_2: 192.168.120.40

results:
    test_db_url: http://213.77.62.197
| | | In this case. This parameter should always set to "keystone" | | | 3) host: which is the name of a control node being attacked. | | | | | | e.g. | | | -fault_type: "kill-process" | | | -process_name: "keystone" | | | -host: node1 | | | | +--------------+--------------------------------------------------------------+ |monitors | In this test case, two kinds of monitor are needed: | | | 1. the "openstack-cmd" monitor constantly request a specific | | | Openstack command, which needs two parameters: | | | 1) monitor_type: which is used for finding the monitor class | | | and related scritps. It should be always set to | | | "openstack-cmd" for this monitor. | | | 2) command_name: which is the command name used for request. | | | In this case, the command name should be keystone related | | | commands. | | | | | | 2. the "process" monitor check whether a process is running | | | on a specific node, which needs three parameters: | | | 1) monitor_type: which used for finding the monitor class and| | | related scritps. It should be always set to "process" | | | for this monitor. | | | 2) process_name: which is the process name for monitor | | | 3) host: which is the name of the node runing the process | | | | | | e.g. | | | monitor1: | | | -monitor_type: "openstack-cmd" | | | -command_name: "keystone user-list" | | | monitor2: | | | -monitor_type: "process" | | | -process_name: "keystone" | | | -host: node1 | | | | +--------------+--------------------------------------------------------------+ |metrics | In this test case, there are two metrics: | | | 1)service_outage_time: which indicates the maximum outage | | | time (seconds) of the specified Openstack command request. | | | 2)process_recover_time: which indicates the maximun time | | | (seconds) from the process being killed to recovered | | | | +--------------+--------------------------------------------------------------+ |test tool | Developed by the project. Please see folder: | | | "yardstick/benchmark/scenarios/availability/ha_tools" | | | | +--------------+--------------------------------------------------------------+ |references | ETSI NFV REL001 | | | | +--------------+--------------------------------------------------------------+ |configuration | This test case needs two configuration files: | | | 1) test case file: opnfv_yardstick_tc046.yaml | | | -Attackers: see above "attackers" discription | | | -waiting_time: which is the time (seconds) from the process | | | being killed to stoping monitors the monitors | | | -Monitors: see above "monitors" discription | | | -SLA: see above "metrics" discription | | | | | | 2)POD file: pod.yaml | | | The POD configuration should record on pod.yaml first. | | | the "host" item in this test case will use the node name in | | | the pod.yaml. | | | | +--------------+--------------------------------------------------------------+ |test sequence | description and expected result | | | | +--------------+--------------------------------------------------------------+ |step 1 | start monitors: | | | each monitor will run with independently process | | | | | | Result: The monitor info will be collected. | | | | +--------------+--------------------------------------------------------------+ |step 2 | do attacker: connect the host through SSH, and then execute | | | the kill process script with param value specified by | | | "process_name" | | | | | | Result: Process will be killed. | | | | +--------------+--------------------------------------------------------------+ |step 3 | stop monitors after a period of time specified by | | | "waiting_time" | | | | | | Result: The monitor info will be aggregated. | | | | +--------------+--------------------------------------------------------------+ |step 4 | verify the SLA | | | | | | Result: The test case is passed or not. | | | | +--------------+--------------------------------------------------------------+ |post-action | It is the action when the test cases exist. It will check the| | | status of the specified process on the host, and restart the | | | process if it is not running for next test cases | | | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | | | execution problem. | | | | +--------------+--------------------------------------------------------------+