You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To know about the patterns that you can contribute and use, understand the following pattern tiers:
18
+
To know about the patterns that you can use and contribute towards, understand the following pattern tiers:
19
19
20
20
|===
21
21
|Pattern tier|Description
22
22
23
23
|{sandbox-tier-first}
24
-
|A pattern under the {sandbox} tier or a {sandbox} pattern is one that might be in a work-in-progress state. , might not yet include a demonstration. A customer business problem has potentially not been identified or fully solved
25
-
Might have been manually tested, and on a limited set of platforms
26
-
Not yet reviewed by Red{nbsp}Hat
24
+
|A pattern categorized under the {sandbox} tier is an inclusive and low-risk way to become associated with the {solution-name-upstream} project. The minimum requirement to qualify for the {sandbox} tier is that you must start with the patterns framework and include minimal documentation.
25
+
The patterns in this tier might be in a work-in-progress state; and they might have been manually tested and on a limited set of platforms.
27
26
28
27
29
28
|{tested-tier-first}
30
-
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 {rh-ocp}. 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).|
29
+
|A pattern categorized under theThe {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 {rh-ocp}. 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).
31
30
Clear business problem with demo
32
31
All components are supportable*, and any Red Hat product usage signed-off by BUs
33
32
Test plan (manual or automated) that passes at least once for each new OpenShift minor version within 3 months of GA
34
33
35
34
|{maintained-tier-first}
36
-
|Group 2 plus…
35
+
| intended to provide consumers with additional "sales" collateral and reassurance that the pattern was known to be functional on all currently supported LTS versions of OpenShift. Inclusion in this tier may require additional work for the pattern’s owner - which might be a partner or sufficiently motivated SME.
36
+
Group 2 plus…
37
37
Formal release process with z-streams
38
38
CI automation (either weekly or event driven at a similar interval)
Additional requirements specific to the implementation for all Community, and Validated patterns
15
+
Consider these requirements specific to the implementation for all {solution-name-upstream} and their respective tiers.
16
+
17
+
The requirements are categorized as follows:
18
+
19
+
Must::
20
+
These are non-negotiable, core requirements that must be implemented.
21
+
Should::
22
+
These are important but not critical; their implementation enhances the pattern.
23
+
Can::
24
+
These are optional or desirable features, but their absence does not hinder the pattern.
16
25
17
26
[id="must-implementation-requirements"]
18
27
=== Must
19
28
20
-
. Patterns *MUST* include one or more Git repositories, in a publicly accessible location, containing configuration elements that can be consumed by the OpenShift GitOps operator (ArgoCD) without supplying custom ArgoCD images.
21
-
. Patterns *MUST* be useful without all content stored in private git repos
22
-
. Patterns *MUST* include a list of names and versions of all the products and projects being consumed by the pattern
23
-
. Patterns *MUST* be useful without any sample applications that are private or lack public sources.
29
+
. Patterns must include one or more Git repositories, in a publicly accessible location, containing configuration elements that can be consumed by the {rh-gitops} Operator without supplying custom ArgoCD images.
30
+
. Patterns must be useful without all content stored in private git repos
31
+
. Patterns must include a list of names and versions of all the products and projects being consumed by the pattern
32
+
. Patterns must be useful without any sample applications that are private or lack public sources.
24
33
+
25
34
Patterns must not become useless due to bit rot or opaque incompatibilities in closed source "`applications`".
26
35
27
-
. Patterns *MUST NOT* store sensitive data elements, including but not limited to passwords, in Git
28
-
. Patterns *MUST* be possible to deploy on any IPI-based OpenShift cluster (BYO)
36
+
. Patterns must *not* store sensitive data elements, including but not limited to passwords, in Git
37
+
. Patterns must be possible to deploy on any installer-provisioned infrastructure OpenShift cluster (BYO)
29
38
+
30
39
We distinguish between the provisioning and configuration requirements of the initial cluster ("`Patterns`"), and of clusters/machines managed by the initial cluster (see "`Managed clusters`")
31
40
32
-
. Patterns *MUST* use a standardized https://github.com/validatedpatterns/common/tree/main/clustergroup[clustergroup] Helm chart, as the initial OpenShift GitOps application that describes all namespaces, subscriptions, and any other GitOps applications which contain the configuration elements that make up the solution.
33
-
. Managed clusters *MUST* operate on the premise of "`eventual consistency`" (automatic retries, and an expectation of idempotence), which is one of the essential benefits of the GitOps model.
34
-
. Imperative elements *MUST* be implemented as idempotent code stored in Git
41
+
. Patterns must use a standardized https://github.com/validatedpatterns/common/tree/main/clustergroup[clustergroup] Helm chart, as the initial OpenShift GitOps application that describes all namespaces, subscriptions, and any other GitOps applications which contain the configuration elements that make up the solution.
42
+
. Managed clusters must operate on the premise of "`eventual consistency`" (automatic retries, and an expectation of idempotence), which is one of the essential benefits of the GitOps model.
43
+
. Imperative elements must be implemented as idempotent code stored in Git
35
44
36
45
[id="should-implementation-requirements"]
37
46
=== Should
38
47
39
-
. Patterns SHOULD include sample application(s) to demonstrate the business problem(s) addressed by the pattern.
40
-
. Patterns SHOULD try to indicate which parts are foundational as opposed to being for demonstration purposes.
41
-
. Patterns SHOULD use the VP operator to deploy patterns. However anything that creates the OpenShift GitOps subscription and initial clustergroup application could be acceptable.
42
-
. Patterns SHOULD embody the "`openhybridcloudmodel`" unless there is a compelling reason to limit the availability of functionality to a specific platform or topology.
43
-
. Patterns SHOULD use industry standards and Red Hat products for all required tooling
48
+
. Patterns should include sample application(s) to demonstrate the business problem(s) addressed by the pattern.
49
+
. Patterns should try to indicate which parts are foundational as opposed to being for demonstration purposes.
50
+
. Patterns should use the {validated-patterns-op} to deploy patterns. However anything that creates the OpenShift GitOps subscription and initial clustergroup application could be acceptable.
51
+
. Patterns should embody the link:https://www.redhat.com/en/products/open-hybrid-cloud[Open Hybrid Cloud model] unless there is a compelling reason to limit the availability of functionality to a specific platform or topology.
52
+
. Patterns should use industry standards and Red Hat products for all required tooling
44
53
+
45
54
Patterns prefer current best practices at the time of pattern development. Solutions that do not conform to best practices should expect to justify non-conformance and/or expend engineering effort to conform.
46
55
47
-
. Patterns SHOULD NOT make use of upstream/community operators and images except, depending on the market segment, where critical to the overall solution.
56
+
. Patterns should *not* make use of upstream/community Operators and images except, depending on the market segment, where critical to the overall solution.
48
57
+
49
-
Such operators are forbidden to be deployed into an increasing number of customer environments, which limits reuse.
50
-
Alternatives include productizing the operator, and building it in-cluster from trusted sources as part of the pattern.
58
+
Such Operators are forbidden to be deployed into an increasing number of customer environments, which limits reuse.
59
+
Alternatives include productizing the Operator, and building it in-cluster from trusted sources as part of the pattern.
51
60
52
-
. Patterns SHOULD be decomposed into modules that perform a specific function, so that they can be reused in other patterns.
61
+
. Patterns should be decomposed into modules that perform a specific function, so that they can be reused in other patterns.
53
62
+
54
63
For example, Bucket Notification is a capability in the Medical Diagnosis pattern that could be used for other solutions.
55
64
56
-
. Patterns SHOULD use Ansible Automation Platform to drive the declarative provisioning and management of managed hosts (e.g. RHEL). See also "`Imperative elements`".
57
-
. Patterns SHOULD use RHACM to manage policy and compliance on any managed clusters.
58
-
. Patterns SHOULD use RHACM and a https://github.com/validatedpatterns/common/tree/main/acm[standardized acm chart] to deploy and configure OpenShift GitOps to managed clusters.
59
-
. Managed clusters SHOULD be loosely coupled to their hub, and use OpenShift GitOps to consume applications and configuration directly from Git as opposed to having hard dependencies on a centralized cluster.
60
-
. Managed clusters SHOULD use the "`pull`" deployment model for obtaining their configuration.
61
-
. Imperative elements SHOULD be implemented as Ansible playbooks
62
-
. Imperative elements SHOULD be driven declaratively -- by which we mean that the playbooks should be triggered by Jobs and/or CronJobs stored in Git and delivered by OpenShift GitOps.
65
+
. Patterns should use Ansible Automation Platform to drive the declarative provisioning and management of managed hosts (e.g. RHEL). See also "`Imperative elements`".
66
+
. Patterns should use RHACM to manage policy and compliance on any managed clusters.
67
+
. Patterns should use RHACM and a https://github.com/validatedpatterns/common/tree/main/acm[standardized acm chart] to deploy and configure OpenShift GitOps to managed clusters.
68
+
. Managed clusters should be loosely coupled to their hub, and use OpenShift GitOps to consume applications and configuration directly from Git as opposed to having hard dependencies on a centralized cluster.
69
+
. Managed clusters should use the "`pull`" deployment model for obtaining their configuration.
70
+
. Imperative elements should be implemented as Ansible playbooks
71
+
. Imperative elements should be driven declaratively -- by which we mean that the playbooks should be triggered by Jobs and/or CronJobs stored in Git and delivered by OpenShift GitOps.
63
72
64
73
[id="can-implementation-requirements"]
65
74
=== Can
66
75
67
-
. Patterns CAN include additional configuration and/or demo elements located in one or more additional private git repos.
68
-
. Patterns CAN include automation that deploys a known set of clusters and/or machines in a specific topology
69
-
. Patterns CAN limit functionality/testing claims to specific platforms, topologies, and cluster/node sizes
70
-
. Patterns CAN consume operators from established partners (e.g. Hashicorp Vault, and Seldon)
71
-
. Patterns CAN include managed clusters
72
-
. Patterns CAN include details or automation for provisioning managed clusters, or rely on the admin to pre-provision them out-of-band.
73
-
. Patterns CAN also choose to model multi-cluster solutions as an uncoordinated collection of "`initial hub clusters`"
74
-
. Imperative elements CAN interact with cluster state and/or external influences
76
+
. Patterns can include additional configuration and/or demo elements located in one or more additional private git repos.
77
+
. Patterns can include automation that deploys a known set of clusters and/or machines in a specific topology
78
+
. Patterns can limit functionality/testing claims to specific platforms, topologies, and cluster/node sizes
79
+
. Patterns can consume Operators from established partners (e.g. Hashicorp Vault, and Seldon)
80
+
. Patterns can include managed clusters
81
+
. Patterns can include details or automation for provisioning managed clusters, or rely on the admin to pre-provision them out-of-band.
82
+
. Patterns can also choose to model multi-cluster solutions as an uncoordinated collection of "`initial hub clusters`"
83
+
. Imperative elements can interact with cluster state and/or external influences
Copy file name to clipboardExpand all lines: content/learn/maintained.adoc
+15-11Lines changed: 15 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,16 +38,16 @@ specified for the link:/requirements/tested/[Tested tier]
38
38
[id="must-maintained-tier"]
39
39
=== Must
40
40
41
-
. {maintained} pattern *MUST* continue to meet the following criteria to remain in Maintained Tested tier
42
-
. {maintained} pattern *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
43
-
. {maintained} pattern *MUST* only make use of components that are either supported, or easily substitued for supportable equivalents (eg. HashiCorp vault which has community and enterprise variants)
44
-
. {maintained} pattern *MUST NOT* rely on functionality in tech-preview, or hidden behind feature gates
45
-
. {maintained} pattern *MUST* have their architectures reviewed by the PM, TPM, or TMM of each Red Hat product they consume to ensure consistency with the product teams` intentions and roadmaps
46
-
. {maintained} pattern *MUST* include a presentation deck oriented around the business problem being solved and intended for use by the field to sell and promote the solution
47
-
. {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
48
-
. {maintained} pattern *MUST* be tested on all currently supported OpenShift LTS releases
49
-
. {maintained} pattern *MUST* fix breakage in a "timely" manner
50
-
. {maintained} pattern *MUST* document their support policy
41
+
. {maintained} pattern must continue to meet the following criteria to remain in Maintained Tested tier
42
+
. {maintained} pattern must conform to the common technical link:/requirements/implementation/[implementation requirements]
43
+
. {maintained} pattern must only make use of components that are either supported, or easily substitued for supportable equivalents (eg. HashiCorp vault which has community and enterprise variants)
44
+
. {maintained} pattern must *not* rely on functionality in tech-preview, or hidden behind feature gates
45
+
. {maintained} pattern must have their architectures reviewed by the PM, TPM, or TMM of each Red Hat product they consume to ensure consistency with the product teams` intentions and roadmaps
46
+
. {maintained} pattern must include a presentation deck oriented around the business problem being solved and intended for use by the field to sell and promote the solution
47
+
. {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
48
+
. {maintained} pattern must be tested on all currently supported OpenShift LTS releases
49
+
. {maintained} pattern must fix breakage in a "timely" manner
50
+
. {maintained} pattern must document their support policy
51
51
+
52
52
The individual products used in a Validated Pattern are backed by the full Red Hat support experience conditional on the customer's subscription to those products, and the individual products`' support policy.
53
53
+
@@ -57,7 +57,11 @@ The {solution-name-upstream} team is very motivated to address any problems in t
57
57
+
58
58
TODO: Create an aDoc version of our support statement slide
59
59
60
-
. {maintained} pattern *DO NOT* imply an obligation of support for partner or community operators by Red Hat.
60
+
[NOTE]
61
+
====
62
+
The {maintained} pattern *do not* imply an obligation of support for partner or community operators by Red Hat.
Copy file name to clipboardExpand all lines: content/learn/sandbox.adoc
+10-10Lines changed: 10 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,18 +40,18 @@ General requirements for all {solution-name-upstream}
40
40
[id="must-sandbox-tier"]
41
41
=== Must
42
42
43
-
. {sandbox} pattern *MUST* continue to meet the following criteria to remain in the Sandbox tier
44
-
. {sandbox} pattern *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
45
-
. {sandbox} pattern *MUST* be able to be deployed onto a freshly deployed OpenShift cluster without prior modification or tuning
46
-
. {sandbox} pattern *MUST* include a top-level README highlighting the business problem and how the pattern solves it
47
-
. {sandbox} pattern *MUST* include an architecture drawing. The specific tool/format is flexible as long as the meaning is clear.
48
-
. {sandbox} pattern *MUST* undergo an informal technical review by a community leader to ensure that it meets basic reuse standards
49
-
. {sandbox} pattern *MUST* undergo an informal architecture review by a community leader to ensure that the solution has the right components, and they are generally being used as intended.
43
+
. {sandbox} pattern must continue to meet the following criteria to remain in the Sandbox tier
44
+
. {sandbox} pattern must conform to the common technical link:/requirements/implementation/[implementation requirements]
45
+
. {sandbox} pattern must be able to be deployed onto a freshly deployed OpenShift cluster without prior modification or tuning
46
+
. {sandbox} pattern must include a top-level README highlighting the business problem and how the pattern solves it
47
+
. {sandbox} pattern must include an architecture drawing. The specific tool/format is flexible as long as the meaning is clear.
48
+
. {sandbox} pattern must undergo an informal technical review by a community leader to ensure that it meets basic reuse standards
49
+
. {sandbox} pattern must undergo an informal architecture review by a community leader to ensure that the solution has the right components, and they are generally being used as intended.
50
50
+
51
51
For example: not using a database as a message bus.
52
52
As community leaders, contributions from within Red Hat may be subject to a higher level of scrutiny.
53
53
While we strive to be inclusive, the community will have quality standards and generally using the framework does not automatically imply a solution is suitable for the community to endorse/publish.
54
-
. {sandbox} pattern *MUST* document their support policy
54
+
. {sandbox} pattern must document their support policy
55
55
+
56
56
It is anticipated that most{sandbox} pattern will be supported by the community on a best-effort basis, but this should be stated explicitly.
57
57
The {solution-name-upstream} team commits to maintaining the framework but will also accept help.
@@ -60,6 +60,6 @@ The {solution-name-upstream} team commits to maintaining the framework but will
60
60
[id="can-sandbox-tier"]
61
61
=== Can
62
62
63
-
. {sandbox} pattern (including works-in-progress) CAN be hosted in the link:https://github.com/validatedpatterns-sandbox[https://github.com/validatedpatterns-sandbox] GitHub organization
63
+
. {sandbox} pattern (including works-in-progress) can be hosted in the link:https://github.com/validatedpatterns-sandbox[https://github.com/validatedpatterns-sandbox] GitHub organization
64
64
. {sandbox} pattern CAN be listed on the link:https://validatedpatterns.io[https://validatedpatterns.io] site
65
-
. {sandbox} pattern meeting additional criteria CAN be nominated for promotion to the link:/learn/tested/[Tested tier]
65
+
. {sandbox} pattern meeting additional criteria can be nominated for promotion to the link:/learn/tested/[Tested tier]
Copy file name to clipboardExpand all lines: content/learn/test-artefacts.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ aliases: /requirements/tested/
12
12
[id="testing-artefacts"]
13
13
= Testing artefacts
14
14
15
-
In order to be represented in the CI dashboard, testers can create a publically available JSON file (eg. in an AWS bucket) that records the result of the latest test for each combination of pattern, platform, and OpenShift version.
15
+
To be represented in the CI dashboard, testers can 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 {rh-ocp} version.
0 commit comments