validatedpatterns · beekhof · Oct 3, 2023 · Oct 3, 2023 · Oct 3, 2023 · Oct 5, 2023
diff --git a/archetypes/pattern/_index.adoc b/archetypes/pattern/_index.adoc
@@ -13,7 +13,7 @@ industries:
 links:
   install:
   arch:
-  help: https://groups.google.com/g/hybrid-cloud-patterns
+  help: https://groups.google.com/g/validatedpatterns
   bugs:
 # The following parameters are only used for validated patterns. Do not uncomment them unless your pattern is validated.
 # validated:

diff --git a/content/learn/community.adoc b/content/learn/community.adoc
diff --git a/content/learn/maintained.adoc b/content/learn/maintained.adoc
@@ -0,0 +1,65 @@
+---
+menu:
+  learn:
+    parent: Workflow
+title: Validated Patterns - Maintained Tier
+weight: 44
+aliases: /requirements/maintained/
+aliases: /requirements/validated/
+---
+
+:toc:
+
+= The Validated Patterns 'Maintained' Tier 
+
+[id="tldr"]
+== tl;dr
+
+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. 
+
+[id="nominating-a-community-pattern-to-become-validated"]
+== Nominating a Tested Pattern to become Maintained
+
+If there is a Tested pattern that you believe would be a good candidate for promotion to Maintained, you can make that case by emailing [email protected]
+
+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 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
+
+
+[id="requirements"]
+== Requirements
+
+Validated Patterns have deliverable and requirements *in addition* to those
+specified for the link:/requirements/tested/[Tested tier]
+
+[id="must"]
+=== Must
+
+. Maintained Patterns *MUST* continue to meet the following criteria to remain in Maintained Tested tier
+. Maintained Patterns *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
+. Maintained Patterns *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)
+. Maintained Patterns *MUST NOT* rely on functionality in tech-preview, or hidden behind feature gates
+. Maintained Patterns *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
+. Maintained Patterns *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
+. Maintained Patterns *MUST* include test plan automation that runs on every change to the pattern, or a schedule no less frequently than once per week
+. Maintained Patterns *MUST* be tested on all currently supported OpenShift LTS releases
+. Maintained Patterns *MUST* fix breakage in a "timely" manner
+. Maintained Patterns *MUST* document their support policy
++
+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.
++
+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.
++
+The validated patterns 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.
++
+TODO: Create an aDoc version of our support statement slide
+
+. Maintained Patterns *DO NOT* imply an obligation of support for partner or community operators by Red Hat.
+
+[id="can"]
+=== Can
+
+. Teams creating Validated Patterns CAN provide their own SLA
diff --git a/content/learn/sandbox.adoc b/content/learn/sandbox.adoc
@@ -0,0 +1,64 @@
+---
+menu:
+  learn:
+    parent: Workflow
+title: Validated Patterns - Sandbox Tier
+weight: 42
+aliases: /requirements/community/
+aliases: /requirements/sandbox/
+---
+
+:toc:
+
+= The Validated Patterns 'Sandbox' Tier 
+
+[id="tldr"]
+== tl;dr
+
+The Sandbox tier is an inclusive and low-risk way to become associated with the Validated Patterns initiative.  As long as the patterns framework is your starting point, and you include some minimal documentation, then you are welcome here.
+
+[id="onboarding-existing-implementations"]
+== Onboarding Existing Implementations
+
+TODO: A short note on the value of converting existing implementations
+
+The Validated Patterns team has a preference for empowering others, and not
+taking credit for their work.
+
+Where there is an existing application/demo, there is also a strong preference for the originating team to own any changes that are needed for the implementation to become a Validated Pattern.  Alternatively, if the Validated Patterns team drives the conversion, then in order to prevent confusion and duplicated efforts, we are likely to ask for a commitment to phase out use of the previous implementation for future engagements such as demos, presentations, and workshops.
+
+The goal is to avoid bringing a parallel implementation into existence which divides engineering resources, and creates confusion internally and with customers as the implementations drift apart.
+
+In both scenarios the originating team can choose where to host the primary repository, will be given admin permissions to any fork in https://github.com/validatedpatterns , and will receive on-going assistance from the Validated Patterns team.
+
+[id="requirements"]
+== Requirements
+
+General requirements for all Validated Patterns
+
+[id="must"]
+=== Must
+
+. Sandbox Patterns *MUST* continue to meet the following criteria to remain in the Sandbox tier
+. Sandbox Patterns *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
+. Tested Patterns *MUST* be able to be deployed onto a freshly deployed OpenShift cluster without prior modification or tuning
+. Sandbox Patterns *MUST* include a top-level README highlighting the business problem and how the pattern solves it
+. Sandbox Patterns *MUST* include an architecture drawing. The specific tool/format is flexible as long as the meaning is clear.
+. Sandbox Patterns *MUST* undergo an informal technical review by a community leader to ensure that it meets basic reuse standards
+. Sandbox Patterns *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.
++
+For example: not using a database as a message bus.
+As community leaders, contributions from within Red Hat may be subject to a higher level of scrutiny
+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.
+. Sandbox Patterns *MUST* document their support policy
++
+It is anticipated that most sandbox patterns will be supported by the community on a best-effort basis, but this should be stated explicitly.
+The validated patterns team commits to maintaining the framework but will also accept help.
+
+
+[id="can"]
+=== Can
+
+. Sandbox Patterns (including works-in-progress) CAN be hosted in the https://gitops.com/validatedpatterns-sandbox GitHub organization
+. Sandbox Patterns CAN be listed on the https://validatedpatterns.io site
+. Sandbox Patterns meeting additional criteria CAN be nominated for promotion to the link:/learn/tested/[Tested tier]
diff --git a/content/learn/test-artefacts.adoc b/content/learn/test-artefacts.adoc
@@ -0,0 +1,84 @@
+---
+menu:
+  learn:
+    parent: Workflow
+title: Testing Artefacts
+weight: 50
+aliases: /requirements/tested/
+---
+
+:toc:
+
+= Testing Artefacts
+
+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.
+
+== File Naming
+
+`{pattern}-{platform}-{openshift version}-stable-badge.json`
+
+Example: `medicaldiag-nutanix-4.13-stable-badge.json`
+
+Note: OpenShift verion should be `major.minor` only
+
+== File Contents
+
+[source,json]
+----
+  {
+    "schemaVersion":1,
+    "label":"{text}",
+    
+    /* For now we assume `message` is the same as patternBranch */
+    "message":"{text}",
+    
+    /* passed => green, test failed => red, test setup failed => yellow */
+    "color":"{test result color}",
+    
+    /* eg. x.y.z */
+    "openshiftVersion":"{full openshift version}",
+    
+    /* eg. AWS, GCP, Nutanix, ... */
+    "infraProvider":"{platform}",
+    
+    /* Official repo of the pattern, eg. https://github.com/validatedpatterns/multicloud-gitops */
+    "patternRepo": "{text}",
+    
+    /* eg. main, stable-N.M */
+    "patternBranch": "{text}",
+
+    "date":"{YYYY-MM-DD}",
+    
+    /* Who ran the test eg. Red Hat */
+    "testSource": "{company name}",
+    
+    /* eg. Job number */
+    "testID": "{unique id}",
+    
+    /* if publically available */
+    "jenkinsURL":"{path to job}",
+    
+    "debugInfo":"{location of must-gather tarball}",
+  }
+----
+
+=== Example
+
+[source,json]
+----
+  {
+    "schemaVersion":1,
+    "label":"MCG on Nutanix",
+    "message":"main",
+    "color":"green",
+    "openshiftVersion":"4.13.14",
+    "infraProvider":"Nutanix",
+    "patternRepo": "https://github.com/validatedpatterns/multicloud-gitops", 
+    "patternBranch": "main", 
+    "date":"2023-10-23",
+    "testSource": "Red Hat"
+    "testID": "13602",
+    "jenkinsURL":"https://jenkins/job/ValidatedPatterns/job/MedicalDiagnosis/job/medicaldiag-gcp-ocp4.13/37/",
+    "debugInfo":"https://storage.cloud.google.com/.../medicaldiag-gcp-ocp4.13.15-13602.tgz",
+  }
+----
diff --git a/content/learn/tested.adoc b/content/learn/tested.adoc
@@ -0,0 +1,75 @@
+---
+menu:
+  learn:
+    parent: Workflow
+title: Validated Patterns - Tested Tier
+weight: 43
+aliases: /requirements/tested/
+---
+
+:toc:
+
+= The Validated Patterns 'Tested' Tier
+
+[id="tldr"]
+== tl;dr
+
+The Tested tier is intended to provide consumers with additional collateral and reassurance that the pattern was known to be recently working on at least one recent version of OpenShift.  Inclusion in this tier requires some additional work for the pattern's owner - which might be a partner or sufficiently motivated SME.
+
+[id="nominating-a-community-pattern-to-become-Tested"]
+== Nominating a Sandbox Pattern for Promotion to Tested
+
+If there is a Sandbox pattern that you believe would be a good candidate for promotion to tested, you can make that case by emailing [email protected]
+
+Please be aware that each Tested 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 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
+
+
+[id="requirements"]
+== Requirements
+
+Tested Patterns have deliverable and requirements *in addition* to those
+specified for the link:/requirements/sandbox/[Sandbox tier]
+
+[id="must"]
+=== Must
+
+. Tested Patterns *MUST* continue to meet the following criteria to remain in the Tested tier
+. Tested Patterns *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
+. Tested Patterns *MUST* be meaningful without specialized hardware, including flavors of architectures not explicitly supported.
++
+Qualification is a Validated Patterns TOC decision with input from the pattern owner.
+
+. Tested Patterns *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.
+. Tested Patterns *MUST* include a standardized architecture drawing, created with (or at least conforming to) the PAC tooling
+. Tested Patterns *MUST* include a written guide for others to follow when demonstrating the pattern
+. Tested Patterns *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: https://docs.google.com/document/d/12KQhdzjVIsxRURTnWAckiEMB3_96oWBjtlTXi1q73cg/view[Validating an Industrial Edge Deployment]
++
+TODO: Convert above link to adoc
+
+. Tested Patterns *MUST* nominate at least one currently supported OpenShift release to test against
+. Tested Patterns *MUST* ensure the test plan passes at least once per quarter
+. Tested Patterns *MUST* 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. See link:/learn/test-artefacts/[testing artefacts]
+. Tested Patterns *DO NOT* imply an obligation of support for partner or community operators by Red Hat or the pattern owner.
+
+[id="should"]
+=== Should
+
+. Tested Patterns SHOULD be broadly applicable.
+. Tested Patterns SHOULD focus on functionality not performance.
+
+[id="can"]
+=== Can
+
+. Teams creating Tested Patterns CAN provide their own SLA
++
+A document for QE that defines, at a technical level, how to validate if the pattern has been successfully deployed and is functionally operational.
+Example: https://docs.google.com/document/d/12KQhdzjVIsxRURTnWAckiEMB3_96oWBjtlTXi1q73cg/view[Validating an Industrial Edge Deployment]
+
+. Tested Patterns meeting additional criteria CAN be nominated for promotion to the link:/learn/maintained/[Maintained tier]