About the Validated Patterns Tested tier
The tested tier provides you with additional collateral and reassurance that the pattern was known to be recently working on at least one recent version of Red Hat OpenShift Container Platform. Inclusion in this tier requires some additional work for the pattern’s owner, which might be a partner or a sufficiently motivated subject matter expert (SME).
If your pattern qualifies or meets the criteria for tested tier, submit your nomination to firstname.lastname@example.org.
Each tested pattern represents an ongoing maintenance, support, and testing effort. Finite team capacity means that it is not possible for the team to take on this responsibility for all Validated Patterns.
For this reason we have designed the tiers and our processes to facilitate this to occur outside of the team by any sufficiently motivated party, including other parts of Red Hat, partners, and even customers.
In limited cases, the Validated Patterns team may consider taking on that work, however please get in contact at least 4 weeks prior to the end of a given quarter in order for the necessary work to be considered as part of the following quarter’s planning process
A tested patterns have deliverable and requirements in addition to those specified for the Sandbox tier.
The requirements are categorized as follows:
These are nonnegotiable, core requirements that must be implemented.
These are important but not critical; their implementation enhances the pattern.
These are optional or desirable features, but their absence does not hinder the implementation of a pattern.
A tested pattern must continue to meet the following criteria to remain in the tested tier:
A tested pattern must conform to the common technical implementation requirements.
A tested pattern must be meaningful without specialized hardware, including flavors of architectures not explicitly supported.
Qualification is a Validated Patterns Technical Oversight Committee (TOC) decision with input from the pattern owner.
A tested pattern must have their implementation reviewed by the patterns team to ensure that it is sufficiently flexible to function across a variety of platforms, customer environments, and any relevant verticals.
A tested pattern must include a standardized architecture drawing, created with (or at least conforming to) the standard Validated Patterns tooling.
A tested pattern must include a written guide for others to follow when demonstrating the pattern.
A tested pattern must include a test plan covering all features or attributes being highlighted by the demonstration guide. Negative flow tests (such as resiliency or data retention in the presence of network outages) are also limited to scenarios covered by the demonstration guide.
The test plan must define how to validate if the pattern has been successfully deployed and is functionally operational. Example: Validating an Industrial Edge Deployment.
A tested pattern must nominate at least one currently supported Red Hat OpenShift Container Platform release to test against.
A tested pattern must ensure the test plan passes at least once per quarter.
A tested pattern must create a publicly available JSON file (for example, in an AWS bucket) that records the result of the latest test for each combination of pattern, platform, and Red Hat OpenShift Container Platform version. See testing artefacts.
A tested pattern does not imply an obligation of support for partner or community operators by Red Hat or the pattern owner.
A tested pattern should be broadly applicable.
A tested pattern should focus on functionality not performance.
Teams creating tested pattern can provide their own service level agreement (SLA).
A technical document for Quality Engineering (QE) team that defines how to validate if the pattern has been successfully deployed and is functionally operational. For example, see Validating an Industrial Edge Deployment.
A tested pattern meeting additional criteria can be nominated for promotion to the Maintained tier.