Skip to content

Commit

Permalink
Merge branch 'openshift-psap:main' into ui-scale-test
Browse files Browse the repository at this point in the history
  • Loading branch information
@smanda99
smanda99 authored Oct 9, 2024
2 parents b929fb2 + 0ec1980 commit 9b336e7
Show file tree
Hide file tree
Showing 359 changed files with 9,322 additions and 2,107 deletions.
46 changes: 46 additions & 0 deletions .github/workflows/check_generated_toolbox_rst.yml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
# Ensure Ansible 'default' files match the Python entrypoint
name: Ansible defaults match

on:
# Triggers the workflow on push or pull request events but only for the main branch
pull_request:
branches: [main]
push:
branches: [main]
schedule:
- cron: '0 */8 * * *'

jobs:
build:
runs-on: ubuntu-latest

steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0

- name: Install dependencies
run: |
python3 -m pip install fire pyyaml jsonpath_ng joblib
- name: "Ensure that Ansible 'default' files match the Python entrypoint"
run: |
./run_toolbox.py repo generate_toolbox_rst_documentation
- name: Show the difference between the commited files and the regenerated Ansible files
run: |
git diff
- name: Fail the test if there is a mismatch between the roles defaults and the Python entrypoints
run: |
changes=$(git diff | wc -l)
if [ "$changes" -ne "0" ]; then
echo "
There is a mismatch between the roles
defaults and the Python entrypoints.
Make sure you run:
./run_toolbox.py repo generate_toolbox_rst_documentation
When making changes to the Python entrypoints.
"
exit 1
fi
2 changes: 2 additions & 0 deletions docs/README.md → docs/README.rst
View file
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
:orphan:

See the rendered version of TOPSAIL's documentation at this address:

> https://openshift-psap.github.io/topsail/index.html
161 changes: 12 additions & 149 deletions docs/contributing.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -9,44 +9,40 @@ document in a pull request.

---

The primary goal of the repository is to serve as a central repository of the
PSAP team's performance and scale test automation.
The primary goal of the repository is to serve as a central repository
of the PSAP team's performance and scale test automation.

The secondary goal of the repository is to offer a toolbox for setup
and configuration of the cluster for consistently preparing the
systems-under-test for manual experimentation and test development.
The secondary goal of the repository is to offer a toolbox for setting
up and configuring clusters, in preparation of performance and scale test execution.

Getting Started
---------------

Refer to ``testing/skeleton`` for a simple example of the structure of a new test.

Pull Request Guidelines
~~~~~~~~~~~~~~~~~~~~~~~
-----------------------

- Pull Requests (PRs) need to be ``/approve`` and reviewed ``/lgtm`` by
PSAP team members before being merged.

- PRs should have a proper description explaining the problem being
solved, or the new feature being introduced.

- PRs introducing or modifying ``toolbox`` commands should include a
documentation commit, so that ``docs`` is kept up-to-date.

Review Guidelines
~~~~~~~~~~~~~~~~~
-----------------

- Reviews can be performed by anyone interested in the good health of
the repository; but approval and/or ``/lgtm`` is reserved to PSAP
team members at the moment.

- The main merging criteria is to have a successful test run that executes the modified code. Because of the nature of the repository, we can't test all the code paths for all PRs.
- The main merging criteria is to have a successful test run that
executes the modified code. Because of the nature of the repository,
we can't test all the code paths for all PRs.

- In order to save unnecessary AWS cloud time, the testing is not
automatically executed by Prow; it must be manually triggered.


Style Guidelines
~~~~~~~~~~~~~~~~
----------------

YAML style
^^^^^^^^^^
Expand Down Expand Up @@ -91,7 +87,7 @@ to help keeping a consistent code style:
fail: msg="The GFD did not label the nodes"
Coding guidelines
~~~~~~~~~~~~~~~~~
-----------------

* Keep the main log file clean when everything goes right, and store
all the relevant information in the ``{{ artifact_extra_logs_dir
Expand Down Expand Up @@ -137,136 +133,3 @@ Coding guidelines
* use ``git revise --cut <commit>`` to split a commit in two
logical commits
* or simply use ``git commit --amend`` to modify the most recent commit


Code contributions
------------------

Creating new roles in Topsail
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

How roles are organized
^^^^^^^^^^^^^^^^^^^^^^^

Roles in Topsail are standard Ansible roles that are wired into the
run_toolbox.py command line interface.

In Topsail, the roles are in the project’s root folder inside the root
folder, their structure is standard to Ansible like the following:

.. code:: bash
toolbox/
└── roles-example/
├── defaults
│ └── main.yml
├── files
│ └── .keep
├── README.md
├── tasks
│ └── main.yml
├── templates
│ └── example.yml.j2
└── vars
└── main.yml
How default parameters are generated
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Topsail generates automatically all the default parameters in the
``<role>/defaults/main.yml`` file, this is to make sure all the roles
parameters are consistent with what the CLI supports
(``run_toolbox.py``). The file ``<role>/defaults/main.yml`` is rendered
automatically when executing from the project’s root folder
``./run_toolbox.py repo generate_ansible_default_settings``. ###
Including new roles in Topsail’s CLI

1. Creating a Python class for the new role
'''''''''''''''''''''''''''''''''''''''''''

Create a class file to reference the new included role and define the
default parameters that can be referenced from the CLI as parameters.

In the project’s root folder create a ``<new_role_name>.py`` with the
following

::

import os
import json

from topsail._common import RunAnsibleRole, AnsibleRole, AnsibleMappedParams
import ansible_runner

class <new_role_name_class>:
"""
Commands relating to <new_role_name>
"""

@AnsibleRole("<new_role_name>")
@AnsibleMappedParams
def run(self,
<new_role_parameter_1>,
<new_role_parameter_n>,
):
"""
Run <new_role_name>

Args:
<new_role_parameter_1>: First parameter
<new_role_parameter_n>: Nth parameter
"""

return RunAnsibleRole(locals())

2. Including the role class in the Toolbox
''''''''''''''''''''''''''''''''''''''''''

To be able to reach new roles from the CLI they need to be registered in
the main ``Toolbox`` class, to do so edit the file ``__init__.py`` and
include

::

.
.
from topsail.<new_role_name> import <new_role_name_class>

class Toolbox:
"""
The PSAP Operators Toolbox
.
.
"""
def __init__(self):
self.cluster = Cluster
.
.
self.<new_role_name> = <new_role_name_class>

Once the new role class is included in the main ``Toolbox`` class it
should be reachable from the ``run_toolbox.py`` CLI.

3. Rendering the default parameters
'''''''''''''''''''''''''''''''''''

Now, once the new role is created, the role class is added to the
project’s root folder and the CLI entrypoint is included in the
``Toolbox`` class, it is possible to render the role default parameters
from the ``run_toolbox.py`` CLI. To render the default parameters for
all roles execute:

::

./run_toolbox.py repo generate_ansible_default_settings

4. Executing the new role from the toolbox
''''''''''''''''''''''''''''''''''''''''''

Once the role is in the correct folder and the ``Toolbox`` entrypoints
are up to date, this new role can be executed directly from ``run_toolbox.py``
like:

::

./run_toolbox.py <new_role_name> <new_role_parameter_1> <new_role_parameter_n>
Loading

0 comments on commit 9b336e7

Please sign in to comment.