About the Validated Patterns Maintained tier
A pattern categorized under the maintained tier implies that the pattern was known to be functional on all currently supported extended update support (EUS) versions of Red Hat OpenShift Container Platform. Qualifying for this tier might require additional work for the pattern’s owner who might be a partner or a sufficiently motivated subject matter expert (SME).
Nominating a pattern for the maintained tier
If your pattern qualifies or meets the criteria for maintained tier, submit your nomination to validatedpatterns@googlegroups.com.
Each maintained 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, it is recommended that you contact the team at least 4 weeks before the end of a given quarter for the necessary work to be considered as part of the following quarter’s planning process.
Requirements for the maintained tier
The maintained patterns have deliverable and requirements in addition to those specified for the Tested tier.
The requirements are categorized as follows:
- Must
These are nonnegotiable, core requirements that must be implemented.
- Should
These are important but not critical; their implementation enhances the pattern.
- Can
These are optional or desirable features, but their absence does not hinder the implementation of a pattern.
Must
A maintained pattern must continue to meet the following criteria to remain in maintained tier:
A maintained pattern must conform to the common technical implementation requirements.
A maintained pattern must only make use of components that are either supported, or easily substituted for supportable equivalents, for example, HashiCorp vault which has community and enterprise variants.
A maintained pattern must not rely on functionality in tech-preview, or hidden behind feature gates.
A maintained pattern must have their architectures reviewed by a representative of each Red Hat product they consume to ensure consistency with the product teams` intentions and roadmaps. Your patterns SME (eg. services rep) can help coordinate this.
A maintained pattern must include a link to a hosted presentation (Google Slides or similar) intended to promote the solution. The focus should be on the architecture and business problem being solved. No customer, or otherwise sensitive, information should be included.
A maintained pattern must include test plan automation that runs on every change to the pattern, or a schedule no less frequently than once per week.
A maintained pattern must be tested on all currently supported Red Hat OpenShift Container Platform extended update support (EUS) releases.
A maintained pattern must fix breakage in timely manner.
A maintained pattern must document their support policy.
The individual products used in a Validated Patterns are backed by the full Red Hat support experience conditional on the customer’s subscription to those products, and the individual products`s support policy.
Additional components in a Validated Patterns that are not supported by Red Hat; for example, Hashicorp Vault, and Seldon Core, require a customer to obtain support from that vendor directly.
The Validated Patterns team is will try to address any problems in the Validated Patterns Operator, and in the common Helm charts, but cannot not offer any SLAs at this time.
The maintained patterns do not imply an obligation of support for partner or community Operators by Red Hat. |
