Testing: OHS Scenarios
Relevant source files
The following files were used as context for generating this wiki page:
Testing for Oracle HTTP Server (OHS) within the spm-middleware project is facilitated by Molecule, an Ansible-native testing framework. These scenarios provide an automated way to verify the installation, patching, and configuration of OHS across different target environments, such as Rocky Linux 8 and 9. The testing suite ensures that all middleware components required for Cúram Social Program Management are correctly deployed and remain idempotent throughout their lifecycle.
The primary goal of these testing scenarios is to validate the ohs role. This includes checking for successful binary installation, the application of critical security patches via the OPatch tool, and the complex configuration of Oracle wallets and SSL certificates. By using standardized Molecule sequences, developers can ensure that any changes to the role do not break existing middleware deployment patterns.
Infrastructure and Environment Setup
The OHS testing environment can be initialized using either a local Python virtual environment or a containerized Docker-in-Docker (DinD) setup. This flexibility allows for consistent testing in local development environments and CI/CD pipelines.
Development Environment Options
| Method | Description | Primary Commands |
|---|---|---|
| Python venv | Isolated environment for Molecule and Ansible dependencies. | python3 -m venv ~/venv/molecule |
| Docker (DinD) | Uses a specialized Molecule container (spmdevops/molecule) to run tests. | docker build -t molecule:latest . |
| Dev Container | VS Code extension setup for consistent workspace environments. | pip install -r requirements.txt |
Sources: CONTRIBUTING.md:3-10, CONTRIBUTING.md:46-55, README.md:38-50
Molecule Lifecycle Flow
The following diagram illustrates the standard execution sequence for an OHS scenario test. The sequence ensures the environment is clean before testing and validates both initial application and subsequent idempotency.
The Molecule sequence manages the lifecycle of the test container, applying the OHS role during the "Converge" phase and validating the results in the "Verify" phase.
Sources: CONTRIBUTING.md:27-29, README.md:58-60
OHS Role Execution (Converge Phase)
During the converge phase, Molecule executes the roles/ohs tasks. This process is modularized into base installation, optional upgrades, patching, and configuration.
Installation Logic
The ohs role follows a strict order of operations to ensure dependencies are met before final configuration.
The OHS role structure breaks down installation into logical units, allowing for conditional execution based on whether components are already installed.
Sources: roles/ohs/tasks/main.yml:19-45, roles/ohs/tasks/base_install.yml:4-106
Key Task Components
- Package Requirements: The role ensures essential system libraries (e.g.,
binutils,gcc-c++,ksh,libaio-devel) are present. Sources: roles/ohs/tasks/base_install.yml:4-22 - Patch Management: The scenario validates the
OPatchtool version and applies specific patches defined in version-specific variable files (e.g.,v12.2.1.4.250103.yml). Sources: roles/ohs/tasks/patch.yml:2-10, roles/ohs/vars/v12.2.1.4.250103.yml:18-22 - Domain Creation: Uses
wlst.shand a Python script (configOHS.py) to create the standalone OHS domain. Sources: roles/ohs/tasks/config.yml:85-90 - Security/SSL: Tests the creation of front-end and back-end Oracle wallets (
pluginWallet,publicEndPoint) and imports self-signed certificates. Sources: roles/ohs/tasks/config.yml:111-200
Scenario Configuration
Scenarios are defined within the molecule/ directory. Each scenario contains a molecule.yml for infrastructure definition and a converge.yml for execution.
Configuration Parameters
Variable files control the specific version of OHS being tested. For instance, the scenario ohs-v12.2.1.4-rockylinux9 targets version 12.2.1.4.0.
| Parameter | Example Value | Description |
|---|---|---|
ohs_version | 12.2.1.4.250103 | Target patch level for OHS. |
ohs_home | /home/oracle/Oracle/Middleware/HTTP_Oracle_Home | Installation directory. |
ohs_port | 7002 | Default listening port. |
keystore_password | Passw0rd | Password for Oracle Wallets. |
Sources: roles/ohs/defaults/main.yml:3-23, roles/ohs/vars/v12.2.1.4.250103.yml:3-10
Execution Commands
To run a specific OHS scenario, the molecule test command is used with the -s (scenario) flag.
# Run full test suite for OHS on Rocky Linux 9
molecule test -s ohs-v12.2.1.4-rockylinux9
# Run converge without destroying the container (for debugging)
molecule converge -s ohs-v12.2.1.4-rockylinux9 --destroy never
Sources: CONTRIBUTING.md:23-35, README.md:65-68
Verification and Validation
The verification phase uses Ansible assertions to ensure the OHS instance meets the expected state. While the converge.yml applies the role, the verification tasks (typically found in a verify.yml within the scenario folder) perform the following checks:
- Binary Existence: Verifying that the
OHS_HOMEdirectory contains the expected executables. - Version Check: Querying the
registry.xmlor usingopatch lspatchesto confirm the applied patch level matches the test requirements. Sources: roles/ohs/tasks/main.yml:32-37 - Wallet Validity: Ensuring that Oracle wallets exist at the specified
wallet_path. Sources: roles/ohs/tasks/config.yml:101-104 - Service Status: Confirming that the
ohsNM.service(Node Manager) is enabled and active viasystemd. Sources: roles/ohs/tasks/config.yml:256-265
SSL Certificate Workflow
Testing the SSL configuration is a critical part of the OHS scenario, involving multiple steps of credential generation and wallet importation.
The SSL testing logic ensures that the middleware can securely communicate with back-end WebLogic servers and front-end clients.
Sources: roles/ohs/tasks/config.yml:138-230
Summary
Testing OHS scenarios ensures that the automated deployment of Oracle HTTP Server is reliable and repeatable. By leveraging Molecule, the project validates complex installation paths—including base binaries, 19c upgrades, and security patching—while guaranteeing that configurations like SSL wallets and systemd services are correctly applied across different Linux distributions.