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 contribute to the patterns that suit your usecase or to learn about onboarding your own pattern, understand the following pattern tiers.
18
+
The different tiers of {solution-name-upstream} are designed to facilitate ongoing maintenance, support, and testing effort for a pattern. To contribute to a pattern that suits your solution or to learn about onboarding your own pattern, understand the following pattern tiers.
19
19
20
20
|===
21
21
|Pattern tier|Description
22
22
23
-
|{sandbox-tier-first}
24
-
|A pattern categorized under the {sandbox} tier provides you with an entry-point to onboard to the {solution-name-upstream}. The minimum requirement to qualify for the {sandbox} tier is that you must start with the patterns framework and include minimal documentation.
|A pattern categorized under the {sandbox} tier provides you with an entrypoint to onboard to {solution-name-upstream}. The minimum requirement to qualify for the {sandbox} tier is to start with the patterns framework and include minimal documentation.
25
25
26
-
These patterns in this tier might be in a work-in-progress state; and they might have been manually tested on a limited set of platforms.
26
+
The patterns in this tier might be in a work-in-progress state; and they might have been manually tested on a limited set of platforms.
27
27
28
28
29
-
|{tested-tier-first}
30
-
|A pattern categorized under the {tested} tier implies that the pattern was known to be recently working on at least one recent version of {rh-ocp}. 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).
29
+
|link:/requirements/tested/[{tested-tier-first}]
30
+
|A pattern categorized under the {tested} tier implies that the pattern might have been recently working on at least one recent version of {rh-ocp}. Qualifying for this tier might require additional work for the pattern’s owner, who might be a partner or a motivated subject matter expert (SME).
31
31
//Additional work such as?
32
-
These patterns in this tier might have a defined business problem with demonstration. The patterns might have a test plan - manual or automated, which passes at least once for each new {rh-ocp} minor version.
32
+
The patterns in this tier might have a defined business problem with a demonstration. The patterns might have a manual or automated test plan, which passes at least once for each new {rh-ocp} minor version.
33
33
34
-
|{maintained-tier-first}
35
-
|A pattern categorized under the {tested} tier implies that the pattern was known to be functional on all currently supported extended update support (EUS) versions of {rh-ocp}. Qualifying for this tier might require additional work for the pattern’s owner who might be a partner or a sufficiently motivated SME.
|A pattern categorized under the {maintained} tier implies that the pattern might have been functional on all currently supported extended update support (EUS) versions of {rh-ocp}. Qualifying for this tier might require additional work for the pattern’s owner who might be a partner or a motivated SME.
36
36
37
-
These patterns might have a formal release process with z-streams They might have continuous integration (CI) automation testing.
37
+
The patterns in this tier might have a formal release process with patch releases. They might have continuous integration (CI) automation testing.
Copy file name to clipboardExpand all lines: content/learn/implementation.adoc
+20-24Lines changed: 20 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,49 +29,45 @@ These are optional or desirable features, but their absence does not hinder the
29
29
[id="must-implementation-requirements"]
30
30
=== Must
31
31
32
-
. 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.
32
+
. 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 Argo CD images.
33
33
. Patterns must be useful without all content stored in private Git repositories.
34
-
. Patterns must include a list of names and versions of all the products and projects being consumed by the pattern.
34
+
. Patterns must include a list of names and versions of all the products and projects that the pattern consumes.
35
35
. Patterns must be useful without any sample applications that are private or that lack public sources.
36
36
//AI:why application was styled that way
37
37
Patterns must *not* become useless due to bit rot or opaque incompatibilities in closed source applications.
38
-
39
-
. Patterns must *not* store sensitive data elements, including but not limited to passwords, in Git repositories.
38
+
. Patterns must *not* store sensitive data elements, including but not limited to, passwords in Git repositories.
40
39
. Patterns must be possible to deploy on any installer-provisioned infrastructure OpenShift cluster (BYO).
41
40
//AI:why Patterns and Managed clusters is styled that way
42
-
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`).
43
-
44
-
. Patterns must use a standardized https://github.com/validatedpatterns/common/tree/main/clustergroup[clustergroup] Helm chart, as the initial {rh-gitops} application that describes all namespaces, subscriptions, and any other GitOps applications which contain the configuration elements that make up the solution.
45
-
. 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.
46
-
. Imperative elements must be implemented as idempotent code stored in Git
41
+
We distinguish between the provisioning and configuration requirements of the initial cluster (`Patterns`) and of clusters or machines that are managed by the initial cluster (see `Managed clusters`).
42
+
. Patterns must use a standardized https://github.com/validatedpatterns/common/tree/main/clustergroup[clustergroup] Helm chart as the initial {rh-gitops} application that describes all namespaces, subscriptions, and any other GitOps applications which contain the configuration elements that make up the solution.
43
+
. 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.
44
+
. Imperative elements must be implemented as idempotent code stored in Git repository.
47
45
48
46
[id="should-implementation-requirements"]
49
47
=== Should
50
48
51
-
. Patterns should include sample application(s) to demonstrate the business problem(s) addressed by the pattern.
49
+
. Patterns should include sample applications to demonstrate the business problems addressed by the pattern.
52
50
. Patterns should try to indicate which parts are foundational as opposed to being for demonstration purposes.
53
-
. Patterns should use the {validated-patterns-op} to deploy patterns. However anything that creates the {rh-gitops-short} subscription and initial clustergroup application could be acceptable.
51
+
. Patterns should use the {validated-patterns-op} to deploy patterns. However, anything that creates the {rh-gitops-short} subscription and initial clustergroup application could be acceptable.
54
52
. 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.
55
-
. Patterns should use industry standards and Red Hat products for all required tooling
53
+
. Patterns should use industry standards and {redhat} products for all required tooling.
56
54
+
57
-
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.
58
-
59
-
. Patterns should *not* make use of upstream/community Operators and images except, depending on the market segment, where critical to the overall solution.
55
+
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 or expend engineering effort to conform.
56
+
. Patterns should *not* make use of upstream or community Operators and images except, depending on the market segment, where it is critical to the overall solution.
60
57
+
61
-
Such Operators are forbidden to be deployed into an increasing number of customer environments, which limits reuse.
62
-
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 the pattern reuse. Alternatively, consider to productize the Operator, and build it in-cluster from trusted sources as part of the pattern.
63
59
64
60
. Patterns should be decomposed into modules that perform a specific function, so that they can be reused in other patterns.
65
61
+
66
-
For example, Bucket Notification is a capability in the Medical Diagnosis pattern that could be used for other solutions.
62
+
For example, Bucket Notification is a capability in the {med-pattern} that could be used for other solutions.
67
63
68
-
. Patterns should use Ansible Automation Platform to drive the declarative provisioning and management of managed hosts (e.g. RHEL). See also "`Imperative elements`".
69
-
. Patterns should use RHACM to manage policy and compliance on any managed clusters.
70
-
. Patterns should use RHACM and a https://github.com/validatedpatterns/common/tree/main/acm[standardized acm chart] to deploy and configure {rh-gitops-short} to managed clusters.
64
+
. Patterns should use {rh-ansible} to drive the declarative provisioning and management of managed hosts, for example, {rhel-first}. See also `Imperative elements`.
65
+
. Patterns should use {rh-rhacm-first} to manage policy and compliance on any managed clusters.
66
+
. Patterns should use {rh-rhacm} and a https://github.com/validatedpatterns/common/tree/main/acm[standardized RHACM chart] to deploy and configure {rh-gitops-short} to managed clusters.
71
67
. Managed clusters should be loosely coupled to their hub, and use {rh-gitops-short} to consume applications and configuration directly from Git as opposed to having hard dependencies on a centralized cluster.
72
-
. Managed clusters should use the "`pull`" deployment model for obtaining their configuration.
73
-
. Imperative elements should be implemented as Ansible playbooks
74
-
. Imperative elements should be driven declaratively -- by which we mean that the playbooks should be triggered by Jobs or CronJobs stored in Git and delivered by {rh-gitops-short}.
68
+
. Managed clusters should use the `pull` deployment model for obtaining their configuration.
69
+
. Imperative elements should be implemented as Ansible playbooks.
70
+
. Imperative elements should be driven declaratively implying that the playbooks should be triggered by Jobs or CronJobs stored in Git and delivered by {rh-gitops-short}.
The {maintained} tier is 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.
19
+
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 {rh-ocp}. 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 maintained pattern for promotion to a validated pattern
23
23
24
-
If there is a maintained pattern that you believe would be a good candidate for promotion to validated pattern, you can make that case by mailing mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].
25
-
26
-
Please be aware that each Maintained pattern represents an ongoing maintenance, support, and testing effort. Finite team capacity means that it is simply not possible for the team to take on this responsibility for all {solution-name-upstream}.
24
+
If your {maintained} pattern qualifies or meets the criteria for promotion to a {validated} pattern, submit your nomination to mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com].
27
25
26
+
[NOTE]
27
+
====
28
+
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 {solution-name-upstream}.
29
+
====
30
+
//NOte sure about the following bits - needs discussion
28
31
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.
29
32
30
-
In limited cases, the {solution-name-upstream} 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
33
+
In limited cases, the {solution-name-upstream} team may consider taking on that work, however, it is recommended that you contact the team at least 4 weeks prior to the end of a given quarter for the necessary work to be considered as part of the following quarter's planning process.
31
34
32
35
33
36
[id="requirements-maintained-tier"]
34
37
== Requirements
35
38
36
-
{solution-name-upstream} have deliverable and requirements *in addition* to those
37
-
specified for the link:/requirements/tested/[Tested tier]
39
+
The {maintained} patterns have deliverable and requirements in addition to those
40
+
specified for the link:/requirements/tested/[Tested tier].
38
41
39
42
[id="must-maintained-tier"]
40
43
=== Must
41
44
42
45
A {maintained} pattern must continue to meet the following criteria to remain in {maintained} tier:
43
46
44
-
* A {maintained} pattern must conform to the common technical link:/requirements/implementation/[implementation requirements]
45
-
. {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)
46
-
* A {maintained} pattern must *not* rely on functionality in tech-preview, or hidden behind feature gates
47
-
* A {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
48
-
* A {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
49
-
* 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
50
-
* A {maintained} pattern must be tested on all currently supported OpenShift LTS releases
51
-
* A {maintained} pattern must fix breakage in timely manner
52
-
* A {maintained} pattern must document their support policy
47
+
* A {maintained} pattern must conform to the common technical link:/requirements/implementation/[implementation requirements].
48
+
. 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.
49
+
* A {maintained} pattern must *not* rely on functionality in tech-preview, or hidden behind feature gates.
50
+
* A {maintained} pattern must have their architectures reviewed by the Product Manager (PM), Technical Product Manager (TPM), or Technical Marketing Manager (TMM) of each {redhat} product they consume to ensure consistency with the product teams` intentions and roadmaps.
51
+
* A {maintained} pattern must include a presentation slides oriented around the business problem being solved and intended for use by the field to sell and promote the solution.
52
+
* 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.
53
+
* A {maintained} pattern must be tested on all currently supported {rh-ocp} extended update support (EUS) releases.
54
+
* A {maintained} pattern must fix breakage in timely manner.
55
+
* A {maintained} pattern must document their support policy.
53
56
+
54
-
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`s support policy.
57
+
//Needs review by legal?
58
+
The individual products used in a {solution-name-upstream} are backed by the full {redhat} support experience conditional on the customer's subscription to those products, and the individual products`s support policy.
55
59
+
56
-
Additional components in a Validated Pattern that are not supported by Red Hat (e.g. Hashicorp Vault, and Seldon Core) will require a customer to obtain support from that vendor directly.
60
+
Additional components in a {solution-name-upstream} that are not supported by {redhat}; for example, Hashicorp Vault, and Seldon Core, require a customer to obtain support from that vendor directly.
57
61
+
58
-
The {solution-name-upstream} team is very motivated to address any problems in the VP Operator, as well as problems in the common helm charts, but cannot not offer any SLAs at this time.
62
+
//very motivated? will we or won't we?
63
+
The {solution-name-upstream} team is will try to address any problems in the {validated-patterns-op}, and in the common Helm charts, but cannot not offer any SLAs at this time.
59
64
+
60
65
//TODO: Create an aDoc version of our support statement slide
61
66
62
67
[NOTE]
63
68
====
64
-
The {maintained} patterns *do not* imply an obligation of support for partner or community operators by Red Hat.
69
+
The {maintained} patterns *do not* imply an obligation of support for partner or community Operators by {redhat}.
65
70
====
66
71
67
72
[id="can-maintained-tier"]
68
73
=== Can
69
74
70
-
. Teams creating {solution-name-upstream}can provide their own SLA
75
+
. If you are creating {solution-name-upstream}, you can provide your own SLA.
0 commit comments