diff --git a/archetypes/pattern/_index.adoc b/archetypes/pattern/_index.adoc index c10c4abf0..15b7495d6 100644 --- 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 deleted file mode 100644 index 3f40e0f9f..000000000 --- a/content/learn/community.adoc +++ /dev/null @@ -1,43 +0,0 @@ ---- -menu: - learn: - parent: Workflow -title: Community Patterns -weight: 42 -aliases: /requirements/community/ ---- - -:toc: - -= Community Pattern Requirements - -[id="tldr"] -== tl;dr - -* *What are they:* Best practice implementations conforming to the Validated Patterns implementation practices -* *Purpose:* Codify best practices and promote collaboration between different groups inside, and external to, Red Hat -* *Creator:* Customers, Partners, GSIs, Services/Consultants, SAs, and other Red Hat teams - -[id="requirements"] -== Requirements - -General requirements for all Community, and Validated patterns - -[id="base"] -=== Base - -. Patterns *MUST* include a top-level README highlighting the business problem and how the pattern solves it -. Patterns *MUST* include an architecture drawing. The specific tool/format is flexible as long as the meaning is clear. -. Patterns *MUST* undergo an informal architecture review by a community leader to ensure that the solution has the right products, 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. - -. Patterns *MUST* undergo an informal technical review by a community leader to ensure that it conforms to the link:/requirements/implementation/[technical requirements] and meets basic reuse standards -. Patterns *MUST* document their support policy -+ -It is anticipated that most community 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. - -. Patterns SHOULD include a recorded demo highlighting the business problem and how the pattern solves it diff --git a/content/learn/maintained.adoc b/content/learn/maintained.adoc new file mode 100644 index 000000000..a6dc5f6f0 --- /dev/null +++ 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 validatedpatterns@googlegroups.com + +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 new file mode 100644 index 000000000..3f4d63d30 --- /dev/null +++ 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 new file mode 100644 index 000000000..60a6f5095 --- /dev/null +++ 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", + } +---- \ No newline at end of file diff --git a/content/learn/tested.adoc b/content/learn/tested.adoc new file mode 100644 index 000000000..17dda29d3 --- /dev/null +++ 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 validatedpatterns@googlegroups.com + +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] diff --git a/content/learn/validated.adoc b/content/learn/validated.adoc deleted file mode 100644 index 8e60f5318..000000000 --- a/content/learn/validated.adoc +++ /dev/null @@ -1,123 +0,0 @@ ---- -menu: - learn: - parent: Workflow -title: Validated Patterns -weight: 43 -aliases: /requirements/validated/ ---- - -:toc: - -= Validated Pattern Requirements - -[id="tldr"] -== tl;dr - -* *What are they:* Technical foundations, backed by CI, that have succeeded in the market and Red Hat expects to be repeatable across customers and segments. -* *Purpose:* Reduce risk, accelerate sales cycles, and allow consulting organizations to be more effective. -* *Creator:* The Validated Patterns team in conjunction with: Partners, GSIs, Services/Consultants, SAs, and other Red Hat teams - -[id="onboarding-existing-implementations"] -== Onboarding Existing Implementations - -The Validated Patterns team has a preference for empowering other, 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 Red Hat 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/hybrid-cloud-patterns, -and will receive on-going assistance from the Validated Patterns team. - -[id="nominating-a-community-pattern-to-become-validated"] -=== Nominating a Community Pattern to become Validated - -If there is a community pattern that you believe would be a good candidate for -becoming validated, please email hybrid-cloud-patterns@googlegroups.com 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. - -Please be aware that each Validated Pattern represents an ongoing maintenance, support, -and CI effort. Finite team capacity means we must critically balance this cost against -the potential customer opportunity. A "`no`" or "`not yet`" result is not intended as an -insult against the pattern or its author. - -[id="requirements"] -== Requirements - -Validated Patterns have deliverable and requirements in addition to those -specified for link:/requirements/community/[Community-level] patterns - -[id="must"] -=== Must - -. Validated Patterns *MUST* contain more than two RH products. Alternative: Engage with the BU -. Validated Patterns, or the solution on which they are based, *MUST* have been deployed and approved for use in at least one customer environment. -+ -Alternative: link:/requirements/community[Community Pattern] - -. Validated Patterns *MUST* be meaningful without specialized hardware, including flavors of architectures not explicitly supported. Alternative: Engage with DCI -+ -Qualification is a Validated Patterns engineering decision with input from the pattern owner. - -. Validated Patterns *MUST* be broadly applicable. Alternative: Engage with Phased Gate and/or TAMs -+ -Qualification is a Validated Patterns PM decision with input from the pattern owner. - -. Validated Patterns *MUST* only make use of Red Hat products that are already fully supported by their product team(s). -. Validated Patterns *MUST NOT* rely on functionality in tech-preview, or hidden behind feature gates. -. Validated Patterns *MUST* conform to the same Community-level link:/requirements/implementation/[implementation requirements] -. Validated 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 -. Validated 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. -. Validated Patterns *MUST* include a standardized architecture drawing, created with (or at least conforming to) the PAC tooling -. Validated 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 -. Validated Patterns *MUST* include a recorded demo highlighting the business problem and how the pattern solves it -. Validated Patterns *MUST* include a test plan covering all features or attributes being highlighted by the demo that also spans multiple products. Negative flow tests (such as resiliency or data retention in the presence of network outages) are limited to scenarios covered by the demonstration script. -. Validated Patterns *MUST* include automated CI testing that runs on every change to the pattern, or a schedule no less frequently than once per week -. Validated Patterns *MUST* create a new point release of the validation-level deliverables when minor versions (e.g. "`12`" in OpenShift 4.12) of consumed products change -. Validated 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. -See also our standard disclaimer - -. Validated Patterns *DO NOT* imply an obligation of support for partner or community operators by Red Hat. - -[id="should"] -=== Should - -. Validated Patterns SHOULD focus on functionality not performance. -. Validated Patterns SHOULD trigger CI runs for new versions of consumed products -. Validated Patterns SHOULD provide an RHPDS lab environment -+ -A bare bones environment into which the solution can be deployed, and a list of instructions for doing so (e.g. installing and configuring OpenShift GitOps) - -. Validated Patterns SHOULD provide pre-built demo environment using RHPDS -+ -Having an automated demo within the RHPDS system, that will be built based on the current stable version that is run against the CI testing system - -. Validated Patterns SHOULD track deployments of each validation-level deliverable -+ -For lifecycle decisions like discontinuing support of a version -For notification if problems are found in our CI - -[id="can"] -=== Can - -. Teams creating Validated 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] diff --git a/content/patterns/ansible-edge-gitops/_index.md b/content/patterns/ansible-edge-gitops/_index.md index 05cc00b9e..bd6bd6423 100644 --- a/content/patterns/ansible-edge-gitops/_index.md +++ b/content/patterns/ansible-edge-gitops/_index.md @@ -15,7 +15,7 @@ aliases: /ansible-edge-gitops/ pattern_logo: ansible-edge.png links: install: getting-started - help: https://groups.google.com/g/hybrid-cloud-patterns + help: https://groups.google.com/g/validatedpatterns bugs: https://github.com/hybrid-cloud-patterns/ansible-edge-gitops/issues ci: aegitops --- diff --git a/content/patterns/ansible-edge-gitops/ansible-automation-platform.md b/content/patterns/ansible-edge-gitops/ansible-automation-platform.md index 49f00410f..59e9329f4 100644 --- a/content/patterns/ansible-edge-gitops/ansible-automation-platform.md +++ b/content/patterns/ansible-edge-gitops/ansible-automation-platform.md @@ -189,5 +189,5 @@ This does the work of provisioning the kiosk, which configures kiosk mode, and a # Next Steps -## [Help & Feedback](https://groups.google.com/g/hybrid-cloud-patterns) +## [Help & Feedback](https://groups.google.com/g/validatedpatterns) ## [Report Bugs](https://github.com/hybrid-cloud-patterns/ansible-edge-gitops/issues) diff --git a/content/patterns/ansible-edge-gitops/getting-started.md b/content/patterns/ansible-edge-gitops/getting-started.md index 63d323b0d..8a612d627 100644 --- a/content/patterns/ansible-edge-gitops/getting-started.md +++ b/content/patterns/ansible-edge-gitops/getting-started.md @@ -232,5 +232,5 @@ As part of this pattern HashiCorp Vault has been installed. Refer to the section # Next Steps -## [Help & Feedback](https://groups.google.com/g/hybrid-cloud-patterns) +## [Help & Feedback](https://groups.google.com/g/validatedpatterns) ## [Report Bugs](https://github.com/hybrid-cloud-patterns/ansible-edge-gitops/issues) diff --git a/content/patterns/ansible-edge-gitops/ideas-for-customization.md b/content/patterns/ansible-edge-gitops/ideas-for-customization.md index 69f784b5b..bcc2d815e 100644 --- a/content/patterns/ansible-edge-gitops/ideas-for-customization.md +++ b/content/patterns/ansible-edge-gitops/ideas-for-customization.md @@ -264,5 +264,5 @@ The reason this pattern ships with a script as it does instead of invoking the r # Next Steps -## [Help & Feedback](https://groups.google.com/g/hybrid-cloud-patterns) +## [Help & Feedback](https://groups.google.com/g/validatedpatterns) ## [Report Bugs](https://github.com/hybrid-cloud-patterns/ansible-edge-gitops/issues) diff --git a/content/patterns/ansible-edge-gitops/installation-details.md b/content/patterns/ansible-edge-gitops/installation-details.md index 1e9920df7..4347157c1 100644 --- a/content/patterns/ansible-edge-gitops/installation-details.md +++ b/content/patterns/ansible-edge-gitops/installation-details.md @@ -129,5 +129,5 @@ More details of the specifics of how AAP is configured are available [here](/ans # Next Steps -## [Help & Feedback](https://groups.google.com/g/hybrid-cloud-patterns) +## [Help & Feedback](https://groups.google.com/g/validatedpatterns) ## [Report Bugs](https://github.com/hybrid-cloud-patterns/ansible-edge-gitops/issues) diff --git a/content/patterns/ansible-edge-gitops/openshift-virtualization.md b/content/patterns/ansible-edge-gitops/openshift-virtualization.md index d73643232..9d9e862af 100644 --- a/content/patterns/ansible-edge-gitops/openshift-virtualization.md +++ b/content/patterns/ansible-edge-gitops/openshift-virtualization.md @@ -353,5 +353,5 @@ The [rhel8-kiosk-with-svc](https://github.com/hybrid-cloud-patterns/ansible-edge # Next Steps -## [Help & Feedback](https://groups.google.com/g/hybrid-cloud-patterns) +## [Help & Feedback](https://groups.google.com/g/validatedpatterns) ## [Report Bugs](https://github.com/hybrid-cloud-patterns/ansible-edge-gitops/issues) diff --git a/content/patterns/devsecops/_index.md b/content/patterns/devsecops/_index.md index 7f7baa0c5..08e74d2cf 100644 --- a/content/patterns/devsecops/_index.md +++ b/content/patterns/devsecops/_index.md @@ -15,7 +15,7 @@ aliases: /devsecops/ # pattern_logo: devsecops.png links: install: getting-started - help: https://groups.google.com/g/hybrid-cloud-patterns + help: https://groups.google.com/g/validatedpatterns bugs: https://github.com/hybrid-cloud-patterns/multicluster-devsecops/issues ci: devsecops --- diff --git a/content/patterns/devsecops/getting-started.md b/content/patterns/devsecops/getting-started.md index 81a2f130f..1b531c378 100644 --- a/content/patterns/devsecops/getting-started.md +++ b/content/patterns/devsecops/getting-started.md @@ -263,7 +263,7 @@ Advanced Cluster Security needs to be integrated with Quay Enterprise registry. # Next Steps -[Help & Feedback](https://groups.google.com/g/hybrid-cloud-patterns){: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } +[Help & Feedback](https://groups.google.com/g/validatedpatterns){: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } [Report Bugs](https://github.com/hybrid-cloud-patterns/multicluster-devsecops/issues){: .btn .btn-red .fs-5 .mb-4 .mb-md-0 .mr-2 } Once the hub has been setup correctly and confirmed to be working, you can: diff --git a/content/patterns/emerging-disease-detection/_index.adoc b/content/patterns/emerging-disease-detection/_index.adoc index 9f804d905..524029fa6 100644 --- a/content/patterns/emerging-disease-detection/_index.adoc +++ b/content/patterns/emerging-disease-detection/_index.adoc @@ -15,7 +15,7 @@ aliases: /emerging-disease-detection/ links: install: getting-started arch: https://www.redhat.com/architect/portfolio/architecturedetail?ppid=6 - help: https://groups.google.com/g/hybrid-cloud-patterns + help: https://groups.google.com/g/validatedpatterns bugs: https://github.com/validatedpatterns/emerging-disease-detection/issues ci: edd --- diff --git a/content/patterns/emerging-disease-detection/getting-started.adoc b/content/patterns/emerging-disease-detection/getting-started.adoc index 48311d083..7f426dfad 100644 --- a/content/patterns/emerging-disease-detection/getting-started.adoc +++ b/content/patterns/emerging-disease-detection/getting-started.adoc @@ -225,5 +225,5 @@ TO-DO: Describe how to examine the various parts of the Sepsis application = Next Steps -link:https://groups.google.com/g/hybrid-cloud-patterns[Help & Feedback] +link:https://groups.google.com/g/validatedpatterns[Help & Feedback] link:https://github.com/validatedpatterns/emerging-disease-detection/issues[Report Bugs] diff --git a/content/patterns/industrial-edge/_index.md b/content/patterns/industrial-edge/_index.md index f67578294..6307c4ce2 100644 --- a/content/patterns/industrial-edge/_index.md +++ b/content/patterns/industrial-edge/_index.md @@ -16,7 +16,7 @@ pattern_logo: industrial-edge.png links: install: getting-started arch: https://www.redhat.com/architect/portfolio/architecturedetail?ppid=26 - help: https://groups.google.com/g/hybrid-cloud-patterns + help: https://groups.google.com/g/validatedpatterns bugs: https://github.com/hybrid-cloud-patterns/industrial-edge/issues ci: manuela --- diff --git a/content/patterns/industrial-edge/getting-started.md b/content/patterns/industrial-edge/getting-started.md index 021e0b5a6..becfb9b73 100644 --- a/content/patterns/industrial-edge/getting-started.md +++ b/content/patterns/industrial-edge/getting-started.md @@ -227,7 +227,7 @@ For installation tooling dependencies, see [Patterns quick start]({{< ref "/cont ## Next Steps -[Help & Feedback](https://groups.google.com/g/hybrid-cloud-patterns){: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } +[Help & Feedback](https://groups.google.com/g/validatedpatterns){: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } [Report Bugs](https://github.com/hybrid-cloud-patterns/industrial-edge/issues){: .btn .btn-red .fs-5 .mb-4 .mb-md-0 .mr-2 } Once the data center has been setup correctly and confirmed to be working, you can: diff --git a/content/patterns/industrial-edge/ideas-for-customization.md b/content/patterns/industrial-edge/ideas-for-customization.md index e8a064b23..542c65a4c 100644 --- a/content/patterns/industrial-edge/ideas-for-customization.md +++ b/content/patterns/industrial-edge/ideas-for-customization.md @@ -61,5 +61,5 @@ The idea is that this pattern can be used for other use cases keeping the main c What ideas for customization do you have? Can you use this pattern for other use cases? Let us know through our feedback link below. -[Help & Feedback](https://groups.google.com/g/hybrid-cloud-patterns){: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } +[Help & Feedback](https://groups.google.com/g/validatedpatterns){: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } [Report Bugs](https://github.com/hybrid-cloud-patterns/ansible-edge-gitops/issues){: .btn .btn-red .fs-5 .mb-4 .mb-md-0 .mr-2 } diff --git a/content/patterns/medical-diagnosis/_index.adoc b/content/patterns/medical-diagnosis/_index.adoc index fa6cf967d..b8efb9dd0 100644 --- a/content/patterns/medical-diagnosis/_index.adoc +++ b/content/patterns/medical-diagnosis/_index.adoc @@ -14,7 +14,7 @@ pattern_logo: medical-diagnosis.png links: install: getting-started arch: https://www.redhat.com/architect/portfolio/architecturedetail?ppid=6 - help: https://groups.google.com/g/hybrid-cloud-patterns + help: https://groups.google.com/g/validatedpatterns bugs: https://github.com/hybrid-cloud-patterns/medical-diagnosis/issues ci: medicaldiag --- diff --git a/content/patterns/multicloud-gitops-Portworx/_index.md b/content/patterns/multicloud-gitops-Portworx/_index.md index 49892a4a7..18b98c43e 100644 --- a/content/patterns/multicloud-gitops-Portworx/_index.md +++ b/content/patterns/multicloud-gitops-Portworx/_index.md @@ -13,7 +13,7 @@ aliases: /multicloud-gitops-Portworx/ pattern_logo: multicloud-gitops-Portworx.png links: install: getting-started - help: https://groups.google.com/g/hybrid-cloud-patterns + help: https://groups.google.com/g/validatedpatterns bugs: https://github.com/hybrid-cloud-patterns/medical-diagnosis/issues # ci: mcgitopspxe --- diff --git a/content/patterns/multicloud-gitops-Portworx/getting-started.md b/content/patterns/multicloud-gitops-Portworx/getting-started.md index f31c671bf..c23cbe3e0 100644 --- a/content/patterns/multicloud-gitops-Portworx/getting-started.md +++ b/content/patterns/multicloud-gitops-Portworx/getting-started.md @@ -106,5 +106,5 @@ After the management hub is set up and works correctly, attach one or more manag For instructions on deploying the edge, refer to [Managed Cluster Sites](https://validatedpatterns.io/patterns/multicloud-gitops-portworx/managed-cluster/). >Contribute to this pattern: -{{% button text="Help & Feedback" url="https://groups.google.com/g/hybrid-cloud-patterns" %}} +{{% button text="Help & Feedback" url="https://groups.google.com/g/validatedpatterns" %}} {{% button text="Report Bugs" url="https://github.com/portworx/rh-multicloud-gitops-pxe/issues" color-class="btn-red" %}} diff --git a/content/patterns/multicloud-gitops-Portworx/ideas-for-customization.md b/content/patterns/multicloud-gitops-Portworx/ideas-for-customization.md index f04542778..062bab813 100644 --- a/content/patterns/multicloud-gitops-Portworx/ideas-for-customization.md +++ b/content/patterns/multicloud-gitops-Portworx/ideas-for-customization.md @@ -25,5 +25,5 @@ Another idea, after splitting the charts, could be to implement a small Rest API In the end the possibilities to tweak this pattern are endless. Do let us know if you have an awesome idea that you'd like to add >Contribute to this pattern: -[Help & Feedback](https://groups.google.com/g/hybrid-cloud-patterns){: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } +[Help & Feedback](https://groups.google.com/g/validatedpatterns){: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } [Report Bugs](https://github.com/hybrid-cloud-patterns/multicloud-gitops/issues){: .btn .btn-red .fs-5 .mb-4 .mb-md-0 .mr-2 } diff --git a/content/patterns/multicloud-gitops/_index.adoc b/content/patterns/multicloud-gitops/_index.adoc index b42359d72..d7fa8584c 100644 --- a/content/patterns/multicloud-gitops/_index.adoc +++ b/content/patterns/multicloud-gitops/_index.adoc @@ -13,7 +13,7 @@ pattern_logo: multicloud-gitops.png links: install: mcg-getting-started arch: https://www.redhat.com/architect/portfolio/detail/8-hybrid-multicloud-management-with-gitops - help: https://groups.google.com/g/hybrid-cloud-patterns + help: https://groups.google.com/g/validatedpatterns bugs: https://github.com/hybrid-cloud-patterns/multicloud-gitops/issues ci: mcgitops --- diff --git a/content/patterns/retail/_index.md b/content/patterns/retail/_index.md index 64e34fef5..1b6527dd9 100644 --- a/content/patterns/retail/_index.md +++ b/content/patterns/retail/_index.md @@ -14,7 +14,7 @@ aliases: /retail/ # pattern_logo: retail.png links: install: getting-started - help: https://groups.google.com/g/hybrid-cloud-patterns + help: https://groups.google.com/g/validatedpatterns bugs: https://github.com/hybrid-cloud-patterns/retail/issues # uncomment once this exists # ci: retail diff --git a/content/patterns/retail/getting-started.md b/content/patterns/retail/getting-started.md index 845fb7811..fc1e575d1 100644 --- a/content/patterns/retail/getting-started.md +++ b/content/patterns/retail/getting-started.md @@ -164,5 +164,5 @@ Clicking on the respective Kafdrop links will go to a Kafdrop instance that allo ## Next Steps -[Help & Feedback](https://groups.google.com/g/hybrid-cloud-patterns){: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } +[Help & Feedback](https://groups.google.com/g/validatedpatterns){: .btn .fs-5 .mb-4 .mb-md-0 .mr-2 } [Report Bugs](https://github.com/hybrid-cloud-patterns/retail/issues){: .btn .btn-red .fs-5 .mb-4 .mb-md-0 .mr-2 } diff --git a/layouts/partials/footer.html b/layouts/partials/footer.html index 2c2e8ce39..1a17fd23f 100644 --- a/layouts/partials/footer.html +++ b/layouts/partials/footer.html @@ -45,7 +45,7 @@ -->
  • - Mailing list + Mailing list
    • diff --git a/modules/contributing.adoc b/modules/contributing.adoc index 21ced4f3a..c54d3b69e 100644 --- a/modules/contributing.adoc +++ b/modules/contributing.adoc @@ -8,7 +8,7 @@ There are a few different ways you can contribute to Hybrid Cloud Patterns documentation: -* Email the Hybrid Cloud Patterns team at mailto:hybrid-cloud-patterns@googlegroups.com[hybrid-cloud-patterns@googlegroups.com]. +* Email the Hybrid Cloud Patterns team at mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com]. * Create a link:https://github.com/hybrid-cloud-patterns/docs/issues[GitHub] or link:https://issues.redhat.com/projects/MBP/issues[Jira issue] . //to-do: Add link to the contribution workflow when we have a proper one. You might need to create a new file * Submit a pull request (PR). To create a PR, create a local clone of your own fork of the link:https://github.com/hybrid-cloud-patterns/docs[Hybrid Cloud Patterns docs repository], make your changes, and submit a PR. This option is best if you have substantial changes.