Pull Request Checklist¶
- Make sure your change does not break idempotency tests. See Testing (or let CI run the tests for you if you are certain it is idempotent.) If a task cannot be made idempotent, add the tag molecule-idempotence-notest.
- Unless a change is small or doesn't affect users, create an issue on https://pulp.plan.io/projects/pulp . Set the Category to "Installer".
- Add a changelog update.
- Write an excellent Commit Message. Make sure you reference and link to the issue.
- Push your branch to your fork and open a Pull request across forks.
- Add GitHub labels as appropriate.
The tests can be run as they are on GitHub Actions with tox, or they can run with various options using molecule directly.
Install Docker, and add yourself to the group that is authorized to administer containers, and log out and back in to make the permissions change take effect. The authorized group is typically the "docker" group:
gpasswd --add "$(whoami)" docker
NOTE: Docker containers can differ from bare-metal or VM OS installs. They can have different packages installed, they can run different kernels, and so on.
- Install tox. This can be done through the system package manager or into a virtualenv:
python3 -m venv ~/.venvs/pulp_installer pip install --upgrade pip pip install tox
tox. If you only have a subset of the supported Python interpreters available, specify which environments to exercise:
tox -e py36
Run molecule commands.
Test all scenarios on all hosts.
molecule test --all
Test a specific scenario.
molecule test --scenario-name source
Use debug for increased verbosity.
molecule --debug test --all
Create and provision, but don't run tests or destroy.
molecule converge --all
Explanation of Different Molecule Scenarios¶
The molecule scenarios have names like
release-static, which we will refer to as
There is a 3 by 3 matrix of them.
The prefixes are:
release- Install stable release from PyPI
source- Install from git checkout. Different codepaths; preflight check does not exist.
packages- Install from distro (RPM) packages. Even more different codepaths; compatibility checks (preflight) is the job of the repo maintainer.
The suffixes are:
static- Statically specify the roles in the "roles:" syntax in the main playbook, such as in the example playbooks.
dynamic- Run roles 1 at a time via
tasks:in the main playbook. Catches undeclared dependencies between roles, and other dynamic include errors. Covers use cases such as users running a 3rd party role, setting vars, and later running our role. Later on, will probably be replaced with installing pulp against multiple containers, each 1 role.
upgrade- Upgrade an existing Pulp 3.y container, to test upgrading Pulp 3.y. Roles are applied statically. Depends on said containers existing on a registry, and having been built manually (using
docker commitfrom molecule.)
release-static is symlinked to
default, so that commands like
molecule test will use it.
There are other (intentional) differences between tests:
static- These include using unix sockets for the webserver to connect to pulp-api & pulp-content. The remainder use TCP connections (
upgradebecause that's what older installs only did,
dynamicbecause they will become containers soon anyway to test cluster installs.)
dynamic- Due to a limitation of Ansible 2.8 with collections, these are not tested with Ansible 2.8.
To test both webserver solutions we testing
apache as webserver with
All others scenarios use
nginx as a webserver.
sudo dnf install mkdocs python3-pymdown-extensions
pip install mkdocs pymdown-extensions