Testing OpenStack upgrades
Go to file
Alex Katz b12c5d5d12 Test that DHCP lease is correctly served when DHCP agent is down
+changed flake8 to version 3.3.0 to support python3.6

Stop agents and then reboot VM. All the dnsmasq processes should
stay alive while the agents are down to serve existing DHCP leases.

Because of the dnsmasq process is restarted right after the
DHCP agent became UP and running we need to make sure that
we are waiting enough time for the dnsmasq processes to be
available.

Change-Id: I06b8ad68657fef0d381fe4f9f2e85105c181d0c0
2020-03-31 14:21:19 +00:00
devstack Find an external network when no one is provided 2020-02-20 08:23:19 +01:00
doc Remove faults integration documentation 2020-02-19 10:15:23 +01:00
etc/oslo-config-generator Autogenerate config options and sample config file 2019-07-18 17:51:49 +02:00
playbooks Copy test result files to zull logs dir 2020-03-23 22:37:03 +01:00
releasenotes Fix requirements and use ReadTheDocs HTML documentation theme 2019-05-07 17:00:32 +02:00
roles Add role to ensure git is installed 2020-03-26 15:21:35 +01:00
tobiko Test that DHCP lease is correctly served when DHCP agent is down 2020-03-31 14:21:19 +00:00
tools/ci Separate run_tox and make_report tasks 2020-03-23 20:25:24 +00:00
zuul.d Copy test result files to zull logs dir 2020-03-23 22:37:03 +01:00
.ansible-lint Spliting infrared plugin into roles 2020-03-17 11:07:08 +00:00
.coveragerc Relax low coverage trealdshold 2019-10-16 12:51:55 +02:00
.gitignore Spliting infrared plugin into roles 2020-03-17 11:07:08 +00:00
.gitreview OpenDev Migration Patch 2019-04-19 19:51:27 +00:00
.stestr.conf Fix requirements and use ReadTheDocs HTML documentation theme 2019-05-07 17:00:32 +02:00
LICENSE Add common module for handling clients 2018-08-15 16:10:50 +03:00
Pipfile Add tobiko-fault command 2019-03-20 14:14:33 +02:00
README.rst Drop support for Python3.5 2020-01-16 13:07:38 +01:00
Vagrantfile Fix Tox Infrared job 2020-02-18 15:40:01 +01:00
ansible.cfg Let automate coloring in infrared environment 2020-03-26 14:47:13 +01:00
bindep.txt Fix Tox Infrared job 2020-02-18 15:40:01 +01:00
infrared-requirements.txt Use default python for testing infrared plugin 2020-03-23 15:47:59 +01:00
linters-requirements.txt Test that DHCP lease is correctly served when DHCP agent is down 2020-03-31 14:21:19 +00:00
report-requirements.txt Add missing requirement to report environment 2020-03-13 16:04:55 +00:00
requirements.txt Remove unused integrations: os_faults and ansible 2020-02-19 17:35:09 +00:00
setup.cfg Execute test cases with InfraRed plugin on CenOS and Ubuntu 2020-03-20 10:36:35 +00:00
setup.py Add initial structure 2018-08-13 12:58:24 +00:00
test-requirements.txt Update requrements files. 2019-04-08 11:58:37 +02:00
tobiko.conf.example Add simple Octavia traffic scenario 2019-11-26 19:13:53 +00:00
tox.ini Let automate coloring in infrared environment 2020-03-26 14:47:13 +01:00

README.rst

Tobiko

Test Big Cloud Operations

Tobiko is an OpenStack testing framework focusing on areas mostly complementary to Tempest. While tempest main focus has been testing OpenStack rest APIs, the main Tobiko focus would be to test OpenStack system operations while "simulating" the use of the cloud as the final user would.

Tobiko's test cases populate the cloud with workloads such as instances, allows the CI workflow to perform an operation such as an update or upgrade, and then runs test cases to validate that the cloud workloads are still functional.

Project Requirements

Tobiko Python framework is being tested with below Python versions:

  • Python 3.6
  • Python 3.7
  • Python 3.8

and below Linux distributions:

  • CentOS 7 (with Python 3.6 and 3.8)
  • Ubuntu Bionic (with Python 3.6 and 3.7)

The framework is being used for executing test cases. As Tobiko can be executed on nodes that are not part of the cloud to test against, this doesn't mean Tobiko requires cloud nodes have to run with one of tested Python versions or Linux distributions.

Main Project Goals

  • To provide a Python framework to write system scenario test cases.
  • To provide tools for testing OpenStack system operations like update, upgrades and fast forward upgrade.
  • To provide CLI tools to implement a workflow designed to test potentially destructive operations (like rebooting cloud nodes, restarting services or others kinds of fault injections).
  • To provide tools to monitor and recollect the healthy status of the cloud as seen from user perspective (black-box testing) or from inside (white-box testing).

References