Merge "Update README.rst file"

README.rst

@@ -8,7 +8,7 @@ Test Big Cloud Operations
 
 Tobiko is an OpenStack testing framework focusing on areas mostly
 complementary to `Tempest <https://docs.openstack.org/tempest/latest/>`__.
-While tempest main focus has been testing OpenStack rest APIs, the main Tobiko
+While Tempest main focus has been testing OpenStack rest APIs, the main Tobiko
 focus is to test OpenStack system operations while "simulating"
 the use of the cloud as the final user would.
 
@@ -29,28 +29,32 @@ versions:
 
 - Python 3.6
 - Python 3.8
-- Python 3.9 (new)
+- Python 3.9
+- Python 3.10 (new)
 
 and below Linux distributions:
 
 - CentOS 7 / RHEL 7 (with Python 3.6)
 - CentOS 8 / RHEL 8 (with Python 3.6)
+- Fedora 34 (with Python 3.9)
+- Fedora 35 (with Python 3.10)
 - Ubuntu Focal (with Python 3.8)
 
 Tobiko has also been tested for development purposes with below OSes:
 
-- Fedora 31 (with Python 3.7)
-- Fedora 32 (with Python 3.8)
-- Fedora 33 (with Python 3.9)
+- Fedora 31 to 33 (with Python 3.7 to 3.10)
 - OSX (with Python 3.6 and Python 3.8)
 - Ubuntu Bionic (with Python 3.6)
-- Ubuntu Focal (with Python 3.9)
+- Ubuntu Focal (with Python 3.8 and 3.9)
 
 The Tobiko Python framework is being used to implement 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 above Python
 versions or Linux distributions.
 
+There is also a Docker file that can be used to create a container for running
+test cases from any node that do support containers execution.
+
 
 Main Project Goals
 ~~~~~~~~~~~~~~~~~~
@@ -58,21 +62,26 @@ Main Project Goals
 - To test OpenStack and Red Hat OpenStack Platform projects before they are
   released.
 - To provide a Python framework to write system scenario test cases (create
-  and test workloads), to write white boxing test cases (to log to cloud nodes
-  for internal inspection purpose), to write disruptive test cases (to simulate
-  service disruptions like for example rebooting/interrupting a service to
-  verify cloud reliability).
-- To provide Ansible roles to implement a work-flow designed to run an ordered
-  sequence of test cases groups (like for example tests that creates resources
-  and verify they are working, tests that execute cloud disruptions, and finally
-  tests that verify if resources initially created are still working). The main
-  use of these roles is writing continuous integration jobs for Zuul (via bare
-  Ansible roles) or other services like Jenkins (via the InfraRed plug-in).
+  and test workloads).
 - To verify previously created workloads are working fine after executing
   OpenStack nodes update/upgrade.
+- To write white boxing test cases (to log to cloud nodes
+  for internal inspection purpose).
+- To write disruptive test cases (to simulate
+  service disruptions like for example rebooting/interrupting a service to
+  verify cloud reliability).
+- To provide Ansible roles implementing a workflow designed to run an ordered
+  sequence of test suites. For example a workflow could do below steps:
+
+  - creates workloads;
+  - run disruptive test cases (IE reboot OpenStack nodes or services);
+  - verify workloads are still working.
+
+  The main use of these roles is writing continuous integration jobs for Zuul
+  or other services like Jenkins (IE by using the Tobiko InfraRed plug-in).
 - 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).
+  seen from user perspective (black-box testing) or from an inside point of
+  view (white-box testing built around SSH client).
 
 
 References