Testing OpenStack upgrades
Go to file
pinikomarov 55c42252a2 add compute reboot faults tests with added boot vm checks
related bz :
https://bugzilla.redhat.com/show_bug.cgi?id=1797892

Change-Id: Id60ea234827d9568e64ae52313df632a0a42aea4
2020-02-09 11:16:27 +00:00
devstack Make sure Python 3 is installed before running DevStack 2020-01-28 11:37:32 +01:00
doc Remove RTD Pip requirements file. 2019-09-24 11:14:19 +02:00
etc/oslo-config-generator Autogenerate config options and sample config file 2019-07-18 17:51:49 +02:00
infrared Create Tox InfraRed upstream job 2020-01-16 15:53:38 +00:00
playbooks Create Tox InfraRed upstream job 2020-01-16 15:53:38 +00:00
releasenotes Fix requirements and use ReadTheDocs HTML documentation theme 2019-05-07 17:00:32 +02:00
roles Disable report files compression by default 2020-01-28 11:28:05 +01:00
tobiko add compute reboot faults tests with added boot vm checks 2020-02-09 11:16:27 +00:00
tools/ci Fix tools/ci/tox script when 'python' command is not available 2020-01-27 11:38:01 +01:00
zuul.d Disable memory_tacker service 2020-01-27 10:28:08 +01:00
.ansible-lint Create Ansible role to install arbitrary Python version 2019-12-16 10:31:32 +01:00
.coveragerc Relax low coverage trealdshold 2019-10-16 12:51:55 +02:00
.gitignore Revert "Allow to configure undercloud via ssh_config file" 2020-02-09 00:34:07 +02: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
ansible.cfg Create Tox InfraRed upstream job 2020-01-16 15:53:38 +00:00
bindep.txt Use "platform:rhel-8" in bindep to specify it is RHEL8 2020-01-22 15:15:55 +01:00
LICENSE Add common module for handling clients 2018-08-15 16:10:50 +03:00
linters-requirements.txt Add ansible playbooks linters job 2019-12-13 17:35:41 +00:00
Pipfile Add tobiko-fault command 2019-03-20 14:14:33 +02:00
plugin.spec Use tools/ci/tox script for running tests and making reports 2020-01-03 09:52:18 +01:00
README.rst Drop support for Python3.5 2020-01-16 13:07:38 +01:00
report-requirements.txt Use master branch of python-subunit to generate reports 2019-12-18 15:22:11 +00:00
requirements.txt Podman integration 2019-12-23 11:19:40 +01:00
setup.cfg Autogenerate config options and sample config file 2019-07-18 17:51:49 +02: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 Create Tox InfraRed upstream job 2020-01-16 15:53:38 +00:00
Vagrantfile Update Vagrantfile to use networking-ovn with DevStack 2019-11-22 09:22:16 +01:00

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