openshift-ansible narrowed to RHEL node scaleup and upgrades in 4.x clusters

Playbooks that only touch RHEL nodes in an existing 4.x cluster

On master this repository is two playbooks plus the roles they call. The quickstart names exactly two entry points: playbooks/scaleup.yml, which brings RHEL hosts into a cluster, and playbooks/upgrade.yml, which moves those hosts to a newer version. Both are executed from the repository root against an inventory file you supply, and both reach the running cluster through the same variable.

That shape decides who this is for. Nobody starting from bare RHEL machines ends up with a cluster here, because nothing in the playbook surface creates one. The reader being served is an operator who already has a working 4.x cluster and needs it to grow, or needs the RHEL machines inside it patched. Topics attached to the project are ansible and openshift, the primary language on the repository is Python for tooling rather than for the playbooks themselves, and the homepage points at try.openshift.com.

The description still says 3.x while the quickstart starts at 4.x

The repository description says 'Install and config an OpenShift 3.x cluster', and that is the sentence a search result hands you. Open the README and the story changes: the first quickstart heading is 'Install an OpenShift 4.x cluster', and the instruction beneath it is to install a cluster with the OpenShift Installer, a separate program in the openshift/installer repository with its own overview document. No playbook in this tree performs that step.

For 3.x the README sends you to a branch per version and names the 3.11 branch, release-3.11, as the last 3.x release. Anyone still targeting a 3.x deployment therefore has to read a different branch from the one they land on by default, and that default is master, which the README says tracks work in development. Trust the one-line description and you will hunt for a 3.x installer playbook that master does not carry.

Ansible >= 2.9.5 in the README, ansible-core<2.17 in requirements.txt

The stated requirements are short: Ansible >= 2.9.5 and the OpenShift Client, oc, and both sit under a heading labelled localhost, meaning the control node is what has to carry them. Then there is requirements.txt, a file holding one pinned line, ansible-core<2.17, with a comment explaining that versions are pinned so upstream package updates cannot break tests with new APIs or semantics, and that updates should be deliberate.

Those two places describe opposite ends of the same range. The README gives a floor at 2.9.5 and names no ceiling, while the file that actually constrains an environment supplies a ceiling and no floor. setup.py still imports print_function from __future__ and string_types from six, which is Python 2 era compatibility code sitting in a tree that asks for Ansible 2.9.5 or newer. No file at the repository root states a supported Python version, and the README names no supported operating system for the control node either, beyond the RHEL hosts the playbooks manage.

One required variable, and the inventory file the quickstart never creates

Every command in the quickstart points at an inventory file that the quickstart never creates. You are told to create an inventory with the appropriate groups and variables defined, an example lives at inventory/hosts.example, and the required variable list holds a single entry: openshift_kubeconfig_path, the path to the kubeconfig for the cluster. The lead-in to that list reads required variables include, so the real set is wider than one line, and the example file is where the rest of them live.

With that file sitting at inventory/hosts, adding RHEL hosts takes two commands:

cd openshift-ansible
ansible-playbook -i inventory/hosts playbooks/scaleup.yml

The mismatch between inventory/hosts.example and inventory/hosts is left for you to resolve. The README shows neither the copy nor a minimal inventory, and the kubeconfig path is the only stated bridge between your machine and the API server of a cluster the Installer created. At the repository root there is an ansible.cfg for the run, and the role content the playbooks call lives under roles/.

Hook stages let you inject custom tasks into a node upgrade

Upgrades are the half of this repository with an extension point. The README states that custom tasks can be performed during upgrades at different stages of the upgrade, and it points at HOOKS.md for the documentation of those stages. The README itself names no stage, so the hook list lives entirely in that file, and the run itself looks like the scaleup run with a different playbook:

cd openshift-ansible
ansible-playbook -i inventory/hosts playbooks/upgrade.yml

Two gaps sit around that command. Nothing here describes how to interrupt, resume or reverse an upgrade once it has touched a host, and the inventory it expects is the one you assembled yourself. If a node has to return to the cluster later, that procedure is not documented in this repository.

Pylint, yamllint and Python packaging inside the roles tree

The repository is counted as a Python project, and the root explains why. setup.py is a setuptools module holding working helpers: find_files walks a base directory, drops excluded directory names and keeps files matching a regex, while recursive_search walks nested dictionaries looking for one named key, which is how fields are located inside the YAML the roles consume. The imports say what the commands run: PylintCommand from setuptools_lint, yamllint's YamlLintConfig, Format and linter, and string_types from six.

One detail rewards a close read. find_files still takes an include_dirs argument and still builds an include regex, yet the comment above that branch says not to use include_dirs because it is broken. A parameter left dead stays part of the signature, so any caller has to know to leave it alone.

Beside it sit .flake8, .pylintrc, .yamllint, pytest.ini, tox.ini, setup.cfg and a .travis.yml carrying a build badge, plus test/, hack/ and docs/ directories. The last push to master landed on 2026-08-17, the code sits under an Apache-2.0 licence, and the repository publishes no GitHub releases, so there is no tagged build to diff a checkout against.

RPM and container image builds for a tree with two 4.x playbooks

Packaging reaches further than the quickstart does. At the root of a repository whose visible playbooks cover node scaleup and node upgrades there is openshift-ansible.spec for an RPM, an images/ directory, a .dockerignore file, and README_CONTAINER_IMAGE.md devoted to packaging openshift-ansible as a container image. BUILD.md holds the instructions for producing both the RPMs and the container images, and a .tito/ directory sits beside them.

That gap is the practical warning. The build system was laid out for a repository whose job was installing whole clusters, where shipping a versioned RPM and a container image made sense to anyone installing from scratch. On master the playbook surface is two YAML entry points, so an operator who reads the README closely still has to work out which of those artifacts, if any, applies to a host joining a cluster that already exists. The README restates no build command inline and does not name the platforms any resulting image targets.

The OpenShift Installer and OKD are the routes named elsewhere

Two alternatives are named in the README, and both differ in approach rather than in branding. The first is the OpenShift Installer, a separate program in the openshift/installer repository reached through its own installer overview, which creates a 4.x cluster instead of mutating one. The second is OKD, the distribution formerly called OpenShift Origin, whose installing documentation is linked from the same Further reading section, alongside the OpenShift Container Platform installation index. For 3.x, the README points back at the branch named for 3.11.

The choice comes down to who owns the first boot. If nobody has installed the cluster yet, the Installer is the documented path and this repository adds nothing to it. If the cluster already runs and its RHEL hosts need to grow or change version, the scaleup and upgrade playbooks here cover what the Installer does not. The same split explains why the 3.x instructions live on a branch instead of on master.

Editorial conclusion

Adopt this tree when a 4.x cluster already runs and the RHEL hosts inside it need to grow or move versions; leave it alone if you still need to install a cluster, because that step moved to the OpenShift Installer. Verify three things before a run: that the 3.11 branch, not master, matches your cluster generation, that your inventory defines more than openshift_kubeconfig_path, and that HOOKS.md names the upgrade stage you plan to hook. No rollback path is documented here, so rehearse on a spare host first.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. openshift/openshift-ansible on GitHub
4. Project website
5. README