Patterns are categorized into distinct tiers: Sandbox, Tested, and Maintained.
The different tiers of Validated Patterns are designed to facilitate ongoing maintenance, support, and testing efforts for a pattern. The tiering system emphasizes the requirements a pattern meets, rather than focusing on who does the maintenance.
The following table describes each pattern tier and a short description of what the tier means in practice.
| Icon | Pattern tier | Description |
|---|---|---|
| A Sandbox pattern is:
| |
| A Tested pattern is:
| |
| A Maintained pattern is:
|
The Sandbox tier serves as the entry point for onboarding new Validated Patterns. Patterns in this tier are typically in a work-in-progress state and might have only been manually tested on a limited set of platforms. The primary goal for patterns here is to get started with the Validated Patterns framework and establish foundational documentation.
Following are the main characteristics and requirements for patterns to be in the sandbox tier:
Deployability: The pattern must be deployable onto a newly installed OpenShift Container Platform cluster without requiring any modification.
Documentation: The pattern must include a top-level README document highlighting the problem this pattern solves, along with an architecture diagram.
Support policy: The pattern must explicitly document the support policy for the pattern. For patterns in the sandbox tier, it is often community-based best-effort support.
Open contribution: The pattern should encourage contributions and should be open to collaboration from the community.
For patterns in the process of being created, the site indicates the current state of development in the sandbox tier including the link to the source repository for the pattern.
For example, the |
Following are some examples of the patterns in the sandbox tier:
For more information about creating a new pattern, see Creating a pattern.
For more information about nominating your pattern for the Sandbox tier, see Nominating a pattern for the sandbox tier
The Tested tier provides additional assurance that a pattern is functional, reliable, and the pattern creators have put in effort to meet additional criteria.
A pattern categorized under the tested tier indicates that the pattern has been tested within the last quarter on at least the most recent Extended Update Support (EUS) version of Red Hat OpenShift Container Platform. You can view the specifics about the testing, including whether it is manual or automated, on the Status Page.
Following are the main characteristics and requirements for patterns to be in the tested tier:
Business use case and demo*: Must have a defined business use case with a demonstration.
Architecture and guides: Must include a standardized architecture diagram and a written guide for demonstrating the pattern.
Test plan: Must include a test plan covering all highlighted features, defining how to validate successful deployment and operational functionality. The test plan must pass at least once per quarter.
OpenShift Container Platform version testing: Must nominate and test against at least one currently supported OpenShift Container Platform release.
Transparency: Must create a publicly available JSON file that records the result of the latest test for each combination of pattern, platform, and OpenShift Container Platform version.
Focus: Primarily focuses on functionality rather than performance.
Following are some examples of the patterns in the tested tier:
The Maintained tier represents the highest level of validation for a pattern. The Validated Patterns team prioritizes these patterns for continuous testing to ensure they remain functional across OpenShift Container Platform updates and API changes.
Patterns in this tier are functional on the currently supported stable versions of OpenShift Container Platform. This includes the two latest Extended Update Support (EUS) releases and the active standard minor version between them. For example, 4.18 (EUS), 4.19, and 4.20 (EUS).
Additionally, Validated Patterns in this tier undergo rigorous continuous integration (CI) testing. Testing environments are tailored to individual pattern requirements, using platforms such as Google Cloud, AWS, Microsoft Azure, and bare metal. The specific testing environment is listed in the testing results on the pattern page and the CI status page.
Following are the main characteristics and requirements for patterns to be in the maintained tier:
Comprehensive testing: Must include test plan automation that runs on every change to the pattern, or on a schedule no less frequently than once per week. This should be included in the Git repository to allow for others to use these same tests in other environments.
Broad compatibility: Must be tested on a sliding set of OpenShift Container Platform releases, specifically the two latest Extended Update Support (EUS) releases and the active standard minor version between them. For example, 4.18 (EUS), 4.19, and 4.20 (EUS). List any hardware or cloud environment requirements.
Timely fixes: Must fix any breakage in a timely manner.
Product review: Their architectures must be reviewed by representatives of each consumed Red Hat product to ensure consistency with product roadmaps.
Support policy documentation: Must document their support policy.
No Technology Preview features: Do not rely on Technology Preview functionality or features that are hidden behind feature gates. Ensure that all services, features, and capabilities are supportable. This support does not need to come from Red Hat, but a support path must exist.
Following are some examples of the patterns in the maintained tier:
| Feature | Sandbox | Tested | Maintained |
|---|---|---|---|
Deploys on fresh OpenShift without modification | ✓ | ✓ | ✓ |
Useful without private/closed source apps | ✓ | ✓ | ✓ |
Open contribution and collaboration | ✓ | ✓ | ✓ |
Documented support policy | ✓ | ✓ | ✓ |
README with problem statement | ✓ | ✓ | ✓ |
Includes architecture diagram | ✓ | ✓ | ✓ |
Business use case with demo | - | ✓ | ✓ |
Standardized architecture diagram and written guide | - | ✓ | ✓ |
Test plan passes at least once per quarter | - | ✓ | ✓ |
Tested on at least 1 supported OCP version | - | ✓ | ✓ |
Publicly visible test results (JSON) | - | ✓ | ✓ |
Implementation review | - | ✓ | ✓ |
Automated CI pipeline (every change or weekly) | - | - | ✓ |
Tested on 2 latest EUS and active interim versions | - | - | ✓ |
Tested on pre-release bits | - | - | ✓ |
Timely fixes for breakage | - | - | ✓ |
No Tech Preview or feature-gated features | - | - | ✓ |
Includes only supported services and components | - | - | ✓ |
